[HN Gopher] Show HN: Tritium - The Legal IDE in Rust
___________________________________________________________________
Show HN: Tritium - The Legal IDE in Rust
$1,500 an hour and still using the software my grandma used to make
bingo fliers!? Hi HN! I'd like to submit for your consideration
Tritium (https://tritium.legal). Tritium aims to bring the power of
the integrated development environment (IDE) to corporate lawyers.
My name is Drew Miller, and I'm lawyer admitted to the New York
bar. I have spent the last 13 years in and out of corporate
transactional practice, while building side projects in various
languages using vanilla Vim. One day at work, I was asked to
implement a legal technology product at my firm. Of course the only
product available for editing and running programs in a locked-down
environment was VS Code and its friends like Puppeteer from
Microsoft. I was really blown away at all of the capabilities of
go-to definition and out-of-the box syntax highlighting as well as
the debugger integration. I made the switch to a full IDE for my
side projects immediately. And it hit me: why don't we have this
exact same tool in corporate law? Corporate lawyers spent hours
upon hours fumbling between various applications and instances of
Word and Adobe. There are sub-par differencing products that make
`patch` look like the future. They do this while charging you
ridiculous rates. I left my practice a few months later to build
Tritium. Tritium aims to be the lawyer's VS Code: an all-in-one
drafting cockpit that treats a deal's entire document suite as a
single, searchable, AI-enhanced workspace while remaining fast,
local, and secure. Tritium is implemented in pure Rust. It is
cross-platform and I'm excited for the prospect of lawyers running
Linux as their daily driver. It leverages a modified version of the
super fast egui.rs immediate-mode GUI library. The windows build
includes a Rust COM implementation which was probably one of the
more technical challenges other than laying out and rendering the
text. Download a copy at https://tritium.legal/download or try out
a web-only WASM preview here: https://tritium.legal/preview Let me
know your thoughts! Your criticisms are the most important. Thank
you for the time.
Author : piker
Score : 293 points
Date : 2025-06-12 12:06 UTC (1 days ago)
(HTM) web link (tritium.legal)
(TXT) w3m dump (tritium.legal)
| jenadine wrote:
| Really cool to see a native app instead of another Electron or
| browser-based tool.
|
| I'm curious what was your experience like building this in Rust?
| Also, how did you find working with egui, what made you choose
| egui over other UI frameworks?
| piker wrote:
| Agreed! I don't think lawyers would have accepted an Electron
| alternative to super fast Word. Rust gives the raw speed and
| safety necessary to compete.
|
| It's my first Rust project, and I've found Rust to be amazing
| once you cross over the learning hurdle. The biggest issue was
| of course the borrow checker, but for a project like this where
| you aren't really iterating much on the design (as opposed to
| say a game dev), it lets you fly. It saves you from all the big
| mistakes and allows you to comfortably use threads and things.
| No idea how I would have made it without rust_analyzer, though.
|
| Egui was simple to get going, while it has some downsides being
| an immediate mode UI, those are mostly overcome by the caching
| necessary for rendering documents, etc.
| tonyhart7 wrote:
| why you choose egui or you just choose based on what you
| commonly used??
| piker wrote:
| I had been messing around with Imgui relatively recently
| and enjoyed the simplicity. Prior to that I was doing stuff
| with React which is kind of the polar opposite and found
| that to be super laborious. So when I saw egui, I jumped at
| the chance.
| nashashmi wrote:
| Not familiar with law enough to understand how to use it. Maybe
| you could show some boring hours long streams of using it in the
| real world and we would understand
| piker wrote:
| It probably wouldn't make sense to show lawyers what we do,
| either, but there's a kernel of truth there: the product needs
| some development on the onboarding.
| rafram wrote:
| This is pretty interesting! Did you implement the DOCX support
| and rich-text editor from scratch? I'd be concerned about
| interoperability with other editors -- a semi-compatible editor
| losing content/comments added by other software could be a huge
| problem.
| piker wrote:
| Yes! From scratch. It started with a docx library but had to be
| re-implemented from the beginning because that library dropped
| data that wasn't implemented. Tritium's docx implementation is
| more permissive such that it can gracefully failover to just
| pure XML if it can't parse an element via the AST.
| tempfile wrote:
| Spent 15 seconds waiting for the spinner to resolve before I gave
| up.
| piker wrote:
| Apologies for that. I thing the pipe is getting hugged a bit
| here. Unfortunately it's a bit lean so no GCP outages to blame
| it on!
| FoeNyx wrote:
| I too waited for the preview to load, but looking in the
| browser console I saw a file was in 404 (
| /static/tritium-c69b2fe84b82a0da.js ) (so it silently failed
| as soon as "import init, * as bindings from
| '/static/tritium-c69b2fe84b82a0da.js';")
| piker wrote:
| Thanks so much! Shouyld be fixed now
| giancarlostoro wrote:
| > Tritium is implemented in pure Rust.
|
| This beautiful software that looks a bit like VS Code, what did
| you use to make it? I'm guessing Tauri but curious if you used
| something else.
| piker wrote:
| That's very kind -- let's hope the legal profession feels the
| same way. It's certainly inspired by VS code. It's using egui
| (https://github.com/emilk/egui) under the hood. Big hats off to
| Emil Ernerfeldt and the team at rerun (https://app.rerun.io/)
| for the incredible work on a great immediate mode GUI library.
| giancarlostoro wrote:
| I did send it to a lawyer I'm friends with, their hesitation
| comes from putting anything confidential on "unknown
| software" so I think you should really focus on highlighting
| any kind of metrics you keep, and anything that could be
| fully relevant to a legal professional. I also recommend, I
| think you mentioned AI is possible, making that opt-in only.
| piker wrote:
| Yes that battle is won by getting the IT/infosec team's
| approval for the desktop application. Lawyers really don't
| like the WASM version because it seems like you're
| uploading docs to some server (you aren't).
|
| Thanks a ton for the feedback!
| pavon wrote:
| Does it have Reveal Codes? :P
| piker wrote:
| Not yet, and I can't tell if you're being sarcastic, but that's
| exactly the of question its users should be asking :)
| rahultuladhar wrote:
| This seems pretty cool! I tried it out but I ran into an error
| that froze the entire app on the preview. Seems to be related to
| max pages per paragraph.
| piker wrote:
| Ah yes, that is a bug where the layout engine can't fit it
| correctly and gets stuck in a loop. It maxes out rather than
| overflows, but the same effect. It's being worked on, and sorry
| for the inconvenience.
| soulofmischief wrote:
| My understanding working with law firms was that they are pretty
| bought-in to the Microsoft Office ecosystem, how well does
| Tritium integrate? Is the docx format fully supported? Can one
| person use Tritium without affecting others? Other than tabs,
| what does Tritium offer that two Word panes and a file browser
| pane tiled on screen can't cover?
|
| I am interested in developing software in this space, so these
| are earnest questions and not criticism.
| piker wrote:
| > My understanding working with law firms was that they are
| pretty bought-in to the Microsoft Office ecosystem, how well
| does Tritium integrate?
|
| Absolutely. Overbought. They're owned by Microsoft. Go to a
| legal tech conference and there are thousands of vendors and
| not a single MSFT representative. All they want to do is push
| more Azureware on the deep pockets of profitable firms.
|
| > Is the docx format fully supported?
|
| It will be. There are certainly edge case features that don't
| render correctly yet, but those will come. The 80% that we care
| about should work. No data will be dropped, as mentioned
| elsewhere it will just look bad and gracefully degrade behind
| the scenes to a safe representation that ensures the data isn't
| lost.
|
| > Can one person use Tritium without affecting others?
|
| Yes, it's totally private and secure. Using Tritium doesn't
| require any cloud access or anything like that (other than to
| phone home with the auto-update or your LLM integration). I'm
| going to link the history to a separate hidden directory in the
| filesystem a la .git in the future which will allow some basic
| multi-editor features.
|
| > Other than tabs, what does Tritium offer that two Word panes
| and a file browser pane tiled on screen can't cover?
|
| Great question! It does the things lawyers care about: help
| them pick out symbols (defined terms, specifically) and run
| diffs (redlines) cheap and quick. It also renders PDFs (using
| pdfium).
|
| > I am interested in developing software in this space, so
| these are earnest questions and not criticism.
|
| Drop a line to the email in my bio. I'd love to chat offline.
| blacksmith_tb wrote:
| It's a catchy name, though ironically tritium is not legal in the
| US, generally[1] (for "frivolous purposes"). Guess this is
| serious software!
|
| 1: https://www.law.cornell.edu/cfr/text/10/30.19
| piker wrote:
| Can I trademark that slogan? :)
| philsnow wrote:
| I pine for a DSL for legal documents, both because it's tedious
| and tiresome to parse prose like this:
|
| > Except for persons who manufacture, process, produce, or
| initially transfer for sale or distribution self-luminous
| products containing tritium, krypton-85, or promethium-147, and
| except as provided in paragraph (c) of this section, any person
| is exempt from the requirements for a license set forth in
| section 81 of the Act and from the regulations in parts 20 and
| 30 through 36 and 39 of this chapter to the extent that such
| person receives, possesses, uses, transfers, owns, or acquires
| tritium, krypton-85, or promethium-147 in self-luminous
| products manufactured, processed, produced, or initially
| transferred in accordance with a specific license issued
| pursuant to SS 32.22 of this chapter, which license authorizes
| the initial transfer of the product for use under this section.
|
| ... and also because it is ambiguous / error-prone / subject to
| interpretation, especially when figuring out antecedents of
| pronouns, referents, and textual boundaries.
|
| I tried four times to read the above by paragraph without
| reformatting it with some parentheses etc, but failed.
| philsnow wrote:
| .... I _think_ it means that you can make self-luminous
| products without needing a license, as long as you got them
| from somebody who does have a license.
| pclmulqdq wrote:
| I think that's pretty much it but IANAL. Tritium vials are
| available for sale for use in self-luminous products. The
| vials themselves are pretty expensive for what they are,
| and they come with documentation about who initially
| created the vial (or how it was imported).
|
| I have a gun with a tritium-based night sight (so the sight
| dots glow with no light), and it came with documentation
| about the provenance of each of the three tritium vials.
|
| I also believe it is a crime to break open a sealed tritium
| vial.
| PhilipRoman wrote:
| One thing I would really like to see is the mathematical
| and/or notation with the tall single curly bracket (with
| nesting, when appropriate).
|
| I've seen a bulleted list being used for both conjunctions
| and disjunctions within the same document and in both cases
| it was not obvious from context (it was related to conditions
| for receiving funding)
| conartist6 wrote:
| I have designed CSTML with that exact set of usage and
| features in mind. It would be absolutely perfect for what you
| describe. I badly need investors though. Know any lawyers
| interested in investing in a product like you are describing?
| piker wrote:
| Hey guys - I really appreciate the love from Hacker News. It's a
| real honor to get all of these votes and comments. If you like
| the idea and aren't a lawyer but want to help the project move
| forward, please suggest Tritium to the corporate lawyers you
| know.
| felixg3 wrote:
| Super interesting. Working in consulting, often with corporate
| lawyers. Will check it out.
| brundolf wrote:
| Feedback: the UI feels like a direct reference to VSCode, which
| is familiar to software developers, but not to lawyers. If you're
| hoping this will be adopted by lawyers, I would focus on making
| the UX familiar to _them_. Look at software that they already
| use, and mimic those idioms insomuch as it makes sense to do so.
| I would also have the base web domain link to a normal home /info
| page, not to the demo directly. And maybe prefill the demo with
| some actual content (documents/etc) so people can really see what
| it does and how
|
| Good luck!
| piker wrote:
| Great feedback; and I do agree. The HN link goes to the app
| itself because we're impatient, but there is an actual landing
| page most visitors hit.
|
| I've gone back and forth on the UX idea, and while I do agree,
| it's important that Tritium selects for users that are going to
| be able to quickly adopt the newer concepts. Just simply
| presenting a "better Word" isn't really going to move the
| needle. It's really a shift in expectations. That said, I have
| recently backed off defaulting to dark mode to make it feel
| slightly more familiar.
| brundolf wrote:
| I think software people tend to underestimate the value of
| superficial familiarity. By all means, adhere to your new
| concepts and mental model. But even things like coloring,
| placement of the menu bar, the icons that you use, the
| organization of the UI, etc can go a really long way
|
| Think about programming languages- ones that introduce
| radical new concepts may still employ familiar syntax/naming
| to smooth the transition for newcomers. Rust mimicked C++,
| TypeScript extended JS, etc. These languages were made to
| introduce powerful new ways of thinking about code, but by
| _appearing_ as similar as possible to what devs already knew,
| they freed up more brain cycles for people trying to adopt
| them. They didn 't muddy their concept-space for the sake of
| familiarity, but they didn't introduce any more _un_
| familiarity than they actually needed to for the benefits
| they wanted to give
| singleshot_ wrote:
| No attorney who is flummoxed by this UX is going to touch
| an AI product in any meaningful way. Making legal tools for
| lawyers who would otherwise be using cuneiform tablets or
| the dictation pool is a waste of conversation. Looking
| similar to the tools a seventy five year old lawyer uses is
| like making an F1 car that would look familiar to Jackie
| Stewart: yeah, it'd probably help him adapt, but not enough
| to be competitive with an actual car.
|
| Dig the idea of this product, will give it a whirl tonight.
|
| Source: attorney, former dev
| brundolf wrote:
| It's not about being flummoxed, it's about being annoyed
| enough not to give it a chance
|
| How much less adoption would Rust have gotten if it
| looked like OCaml instead of C++?
|
| Its adopters are not stupid, they could have figured out
| alien syntax if they were already convinced of the
| benefit. But selling someone on an entirely new substrate
| for their professional work is a huge ask. You need to
| make it as immediately-palatable as possible, or they'll
| just keep on sailing without giving it a chance.
| touisteur wrote:
| As much as I wish the world to be different, I've heard
| so much whining about the Ada language's not-C-likeness
| that I tend to agree with you.
| NooneAtAll3 wrote:
| > Rust mimicked C++
|
| if anything, it didn't mimick /enough/
| dr_kiszonka wrote:
| I really like the idea. I could see some of my academic
| collaborators use something like this because it has features
| typically only supported when working with plaintext. A lot
| of academics do not love working with LaTeX.
|
| But I would push back a bit against the UX and it being a
| "better Word". It is not immediately clear from looking at
| the website whether you support tracking changes. If you
| support editing Word documents, why aren't basic editing
| features, like font selection, size and weight, exposed in
| the UI. (I am viewing it on mobile Chrome and I might have
| missed it because your page doesn't support pinch to Zoom.)
|
| You don't have to make it look like Word but it must be
| designed to facilitate common interaction patterns needed for
| working with Word documents.
|
| (If you are building it on top of VSCode you could use its
| multiplayer features, which could be a good sell. )
| sails wrote:
| Figure out how to make it uncompromisingly productive for
| power users and then dumb it down, not the other way around
| way around
| alexnewman wrote:
| There's a couple ways to skin it. In fields where people are
| happy with products, i think familiarity is good. In fields
| where people hate the products, you get to go in tabla rasa. In
| this case they take advantage of the form of the interface
| through multisearch et al. Instead of resembling legal
| software, I wonder if they should resemble a court or a
| briefcase?
| tough wrote:
| minor nit: cmd+z is ctrl+z in macos, which felt counter-intuitive
| on an editor
|
| IANAL: idk if lawyers dont do pdfs but tried some research papers
| and PDF rendering could use some love (MacOS)
| piker wrote:
| Noted, and to be fixed. Thank you
| tough wrote:
| I had edited prior message but would be great if supported
| PDF rendering as good as docx! (for research mostly, not a
| lawyer)
| yauneyz wrote:
| If this is Electron, try pdf.js - really good rendering,
| you can create a text layer (for text selection, etc).
| Probably the best result per effort you can get
| tough wrote:
| care to link to repo? alwayss good to have one of these
| at hand
| mdaniel wrote:
| https://github.com/mozilla/pdf.js#readme _(Apache 2)_
| piker wrote:
| One thing it does is cast the PDF to grayscale to render
| for speed (lawyers rarely care about the color of a legal
| doc in PDF), so perhaps I'll make that an adjustable
| setting which will trade off speed for clarity. Otherwise,
| it uses PDFium for PDF rendering so it should come out just
| as well as what you see in a Chromium-based browser.
| tough wrote:
| might be an issue with DPI / Retina screens on macOS?
|
| it's really more blurry than any pdf on chrome
| https://imgur.com/a/AElOuaA
| piker wrote:
| Oh, yes, that is also a cheat code to render them quicker
| -- it downsamples the render to save time. That will
| improve in future versions as Tritium uses spare cycles
| to increase the resolution.
| tough wrote:
| I also noticed when i opened a folder with hundreds of
| big pdf's it choked on it
|
| seems you're doing work on all files when loading, you
| should be more like lazy-loading?
| piker wrote:
| ^ yes it does greedily ingest the PDFs to allow for
| instantaneous search. What it needs (and doesn't yet do)
| is at least multi-thread that parsing step to get a 2-4x
| speedup.
| handfuloflight wrote:
| Say you were going to cold email a lawyer to pitch them to use
| this, what would you write?
| piker wrote:
| Probably something like: "
|
| [Person] - hope you're well! I wanted to put Tritium on your
| radar. It's a word processor jacked on steroids built just for
| transactional lawyers.
|
| From built-in defined term annotation to multi-document
| search/replace to redlining and much, much more, it will help
| your team work faster and more effectively on existing Word
| documents and PDFs. You'll even pick up errors from outside
| counsel.
|
| Tritium runs on Windows, MacOS and even Linux for your most
| tech savvy lawyers.
|
| Please let me know if that might be good for your legal team,
| and I'd love to demo it for you."
| handfuloflight wrote:
| This is a bit too heavy on the feature side. As in, here is
| what this is, not what it will do for you.
|
| What would you say if you were going to focus on a pain point
| and a problem that this specifically solved for you, that it
| can also solve for the other lawyers who are not using this
| and that is not being met by the other options?
| piker wrote:
| Take one feature: redlining. Right now every corporate
| lawyer knows what a pain in the ass it is to do something
| as simple as a diff. It takes probably a full minute
| (imagine if it were like that to run git diff for you!).
| Tritium runs the redline in microseconds, because it's
| built for lawyers.
| 29athrowaway wrote:
| There should be a "build" button that pulled all the legal codes
| for the target jurisdiction and other legally binding documents
| and checked if everything checks out.
|
| And to achieve this you would have to create a machine readable
| format for legal documents, and have a library of them already
| converted to it.
|
| Then you could have a linter that highlighted that you made a
| logical mistake or did something wrong from the perspective of a
| legal guy.
| sanufar wrote:
| This looks great! I'm really stoked to see egui being used for
| the desktop app. While I'm not a lawyer, I was wondering about
| the potential for external references to cases, i.e doc1
| references a case which isn't present locally, which can then be
| navigated to via something like "go to definition". Maybe
| something like an indexer that crossrefs on a database of legal
| cases? Do you have any thoughts on some other use cases? The idea
| of an IDE for lawyers is super cool, can't wait to see where this
| goes!
| piker wrote:
| Thanks so much. Yes, the plan is to package libraries along
| with the product to allow for all kinds of external entities to
| be resolved.
|
| Egui is great!
| aidenn0 wrote:
| Probably dumb question:
|
| Given that many lawfirms bill by the hour, are there incentives
| to make their work more efficient? I.e. if a firm were to adopt
| this tool, can they practically charge more per hour than a firm
| that does not?
| piker wrote:
| Yes, they are not incentivized to adopt new technology in their
| current state. The senior partners don't want to wait around
| for the eventuality of charging more per hour. That's why
| Tritium is marked to in-house lawyers for now.
|
| I talked a little about this back in September:
| https://www.legalinnovators.co.uk/post/legal-innovators-uk-t...
| speerer wrote:
| As a private practice lawyer in a tech-heavy firm, I can
| assure you that not all of us are stuck at the wrong end of
| that paradigm!
| remich wrote:
| As someone who is a (current) software engineer and (former)
| lawyer I find this interesting. Not sure if I'm willing to bet on
| big uptake, though, unless it was through an acquisition by one
| of the big e-discovery companies.
| pbronez wrote:
| Looks great, sharing it with my legal team.
|
| The "Fetch Example" button on the web demo doesn't seem to work.
| It would be nice if the web demo was pre-loaded with some stuff.
| LorenDB wrote:
| I tried coming back to HN using my mouse's back button, but it
| seems Tritium is eating mouse back button events.
| piker wrote:
| Apologies if that's the case. It's just a WASM application
| intended to demo the real desktop application. No nefarious
| purpose there, but perhaps the limitations of the "preview".
| Try the desktop version!
| socalgal2 wrote:
| Couldn't enter Japanese into the web version. Looks like it
| trying to read keys directly. Copy and paste don't work. Right
| clicking doesn't bring up a context menu with system options so
| no looking up words using the locally installed dictionary. No OS
| level spell checking that uses the user's dictionary.
|
| I guess all of that is TBD though I suspect based on the tech
| choices will be way harder than it sounds.
| piker wrote:
| Copy and paste don't work on the web version, but they should
| work (including pasting formatting out into Office products) on
| desktop. Similarly for fonts. If you're using a font that
| contains Japanese characters it should render. It doesn't (yet)
| do a great job on falling back.
|
| Try the download!
| rubyfan wrote:
| I've been dreaming of a better contract writing tool for a while
| now.
|
| I'm not a lawyer but I draft insurance contracts and work with
| reviewing lawyers closely. As a former software developer I miss
| version control, partial includes, conditional logic, etc. I am
| shocked at how poorly supported the business world is by the
| ubiquity of MS Word.
|
| I've been experimenting with Typst now for some time and it has a
| lot of what I want in creating and versioning documents but I
| believe may be too technical to become integrated with existing
| workflows and the non-technical users engaged in the development
| process. Basically my experience is normal users tune out once
| you get outside of even basic MS Word.
|
| I really want a great tool to exist but I'm afraid I'm an outlier
| and unique in my technical ability in this space. Nice to see
| others interested in such a tool.
| jagged-chisel wrote:
| Ah, a kindred spirit. I have been drafting part time for a
| local firm, and I feel like i'm on the cusp of a brilliant
| concept for pulling documents together, presenting case status
| to the lead lawyer ... but I don't have the time to coalesce my
| inklings into a tool.
|
| I think we technical folk need to build technical tools for us
| to use while we explore the space and iterate on something that
| the normies will accept.
|
| If you find anyone willing to invest money so a team can spend
| time on this, please let me know! :-)
| gjayakrishnan wrote:
| I'm part of the team behind Zoho Contracts, focused on
| simplifying how businesses manage contracts across their
| lifecycle -- from authoring, approvals, negotiation, and
| signing to renewals, amendments, compliance, with comprehensive
| analytics built in.
|
| Our document editor is powered by Zoho Writer, offering all the
| capabilities of a word processor along with versioning,
| document assembly, and automation features. On top of this,
| we've built structured version control, clause-level change
| tracking, and workflow-integrated collaboration. This enables
| legal and business teams to work together seamlessly without
| relying on external editors or juggling redlined Word files
| over email.
|
| Just sharing in case anyone else here is tackling similar
| problems or interested in the space.
| segmondy wrote:
| Good stuff on your launch, You need a better demo page. I can't
| see the video, fonts are too small.
| piker wrote:
| Noted, and will be done. Thank you for the feedback. Were you
| on mobile or desktop?
| segmondy wrote:
| desktop and wearing my eyeglass too!
| righthand wrote:
| Recognizing touch controls on the document viewer tab would be
| nice (ex two finger drag is pan, pinch to zoom, etc).
| btown wrote:
| > There are sub-par differencing products that make `patch` look
| like the future.
|
| I absolutely love https://www.draftable.com/compare - it's an
| incredibly intuitive presentation of diffs from arbitrary
| documents, with fuzzy matching even between file types. It's
| great for everything from "what did my cofounder change in this
| version of the deck" to "how can I quickly scan to understand how
| these PDF documents have evolved from a much earlier version." Be
| careful with data security if uploading sensitive documents, of
| course. But it's as effective a general-purpose diffing tool as
| one can imagine.
|
| The real leap past this would be contextual AI extracted
| takeaways during the review or editing process, which begs for a
| specialized IDE. Makes me excited to see that this space is
| evolving!
| treuks wrote:
| Hey, this looks to be pretty interesting and I'm excited to see
| an app made with egui that doesn't look like it uses the default
| theme!
|
| I have no use for this software personally but I feel like it's
| pretty important for me to point out the fact that in your
| license agreement you misspelled the name of the company as
| Tritium Legal Technlogies (Technl instead of Technol).
|
| Cheers on your product. From the small showcase it seems to be
| extremely fast. Developers actually caring about performance
| brings me great joy.
| piker wrote:
| The incredible irony of a typo in legal documentation related
| to a legal drafting application is not lost on me. Thanks very
| much for the positive words and the correction!
| kibibu wrote:
| Could this also be used as a user-facing tool?
|
| e.g. to understand Terms of Use, finance and purchase agreements,
| that sort of thing?
| piker wrote:
| Yes, although that is not the target audience and we'll try to
| avoid spending time generalizing the product too much for
| laypeople to remain laser focused on the target.
| BiraIgnacio wrote:
| Congrats! Great stuff
| dostick wrote:
| It looks like code editor with symbol references. Is that all the
| functionality? I expected document to be tied to some law (or
| part of) and use outline of that law as outline for document, and
| then populating document to cover all the aspects of selected
| law, with AI, and indicating which generated parts were reviewed
| by human.
| passivegains wrote:
| _and then populating document to cover all the aspects of
| selected law_
|
| I'm fairly certain lawyers exist specifically because this is
| infeasible.
| jagged-chisel wrote:
| Not only that but: which subsection of law is specific to
| this case? What additional documentary requirements come with
| citing that law? What's the presentation strategy for the
| target opponent/lawyer/court?
| nyanpasu64 wrote:
| I wonder if textbooks and papers could be easier to understand if
| they had a "go to definition" functionality for technical jargon,
| notation, or reasoning.
| PrivateButts wrote:
| When I went back to college to finish my degree, some of my
| classes used online textbooks from a couple different systems.
| Most had a simple link to a glossary for key terms, but some
| took it a bit farther and had a nice pop-over widget. The nice
| ones also had the ability for you to highlight and annotate
| passages for your own notes. It's less fun though, if you're
| like me and have a hard time reading long-form content on a
| laptop or phone. I ended up getting one of those eink Android
| tablets to make it easier for me to get through the reading.
|
| Shame is that monetization around them is even more
| exploitative than normal textbooks. You don't own them, so you
| can't keep or resell them once you're done, and you typically
| lose access to it about a week after the class ends. Many
| courses also issue assignments and grades through the
| e-textbook, so you're forced to buy it at a price they decide.
| Fortunately work reimbursed mine.
| b0a04gl wrote:
| > "Finally got sick of diffing contracts in Word and emailing
| PDFs back and forth"
|
| this is the actual iceberg. forget ai clause generators and
| buzzwords, 99 percent of the pain is version chaos. localfirst
| editor is cool and imagine pairing that with proper gitstyle
| branching across teams. redlines you can merge without manually
| eyeball.
| gamblor956 wrote:
| Word has offered redline merging for over several decades...
|
| There's a reason it's still the standard in the legal industry.
|
| The funny thing is that Word has tons of functionality that
| techies aren't aware of because they don't actually use it so
| they keep building products around features Word has had for
| years. And then they wonder why their startup failed to get any
| traction.
| piker wrote:
| No, it doesn't work. I'm a long-term lawyer (and a techie),
| so I'm fully aware of Word's features and shortcomings. Most
| corporate lawyers use a product called Litera which is pretty
| good but a clunky COM add-in.
| gamblor956 wrote:
| As I said in another comment: you're basing your entire
| product around doing one feature, but your competition is
| _the entire package._
|
| Redline doesn't appear to be working in Firefox in the web
| demo you have available. As that is supposed to be your
| killer feature I would say that your product isn't yet in
| MVP state. Also, the UI is quite bad and not the slightest
| bit intuitive; it's the kind of UI that only makes sense
| once you already have been using it for a while. As you
| pointed out, most firm lawyers already know and use Litera,
| so you need to not just be better at your one chosen
| feature but you also need to be easier and more intuitive
| to use and you're not.
|
| It's okay for you to be offended by this criticism; this is
| your baby. But I'm being realistic here. You can choose to
| ignore critiques and die stillborn, or address these
| complaints (which other comments have also pointed out) and
| actually make something that a small but sustainable niche
| of lawyers will happily use.
| piker wrote:
| That's not the killer feature. I'm not sure where you got
| that impression. It's the integrated whole which is the
| feature. Sorry it seems not to work on firefox, but I'll
| definitely work on that. It's a desktop application with
| a "web preview" that is being presented here. Most
| lawyers never interact with the web preview (or the
| website for that matter) because it just arrives on their
| desktop.
|
| Agree to disagree on the UX, but points very much
| appreciated!
|
| [Edit: what OS and generally what type of edit? Firefox
| on Windows is working, but perhaps there's a specific
| edit which caused it to crash. Thanks so much!]
| gamblor956 wrote:
| Firefox on Windows was definitely not working.
|
| Hard disagree on the UX. Remember that it's not what
| _you_ think of the UX, it 's what _your users_ think of
| the UX. This is basically like GIMP or Darktable; I 'm
| sure it makes sense to power users who have invested a
| lot of time, but unless you want that tiny group to be
| your market, you need to make the UX way more user-
| friendly.
| irq-1 wrote:
| Consider pitching it as: use the same Word you always
| have, and use these additional tools (diff, go to,
| etc..).
|
| I'd expect most firms to have their own systems for
| backup, versioning, access control, approval, metadata,
| etc.. or at least a human process for such. It should be
| much easier to sell the "extra tools" than software that
| changes their process.
| b0a04gl wrote:
| yeah word has redline merge, but it breaks the moment edits
| arent linear. try merging three branches of the same contract
| across two firms and an in-house team. tracked changes turn
| into spaghetti. no merge conflict UI, no real version graph,
| no concept of rebasing edits. you get a stitched-up doc with
| 20 authors and no idea who changed what when. and once
| someone accepts changes early, half the context's gone. legal
| folks make it work, but that's survival, not support.
| chaostheory wrote:
| It's not good enough. I know because I had to use it for
| comparing different versions of contracts and it was painful.
| 8s2ngy wrote:
| Congratulations on the release! I don't have much to add, but I
| wanted to express how much I love hearing about people with no
| formal software background who identify problems in their daily
| lives, plan, build, and release software to address them. Best of
| luck!
| vorpalclub wrote:
| Just a thought: I think it would be neat if you could include one
| of Mathew Butterick's fonts (https://matthewbutterick.com/), as a
| fellow lawyer/software developer. I don't know how practical that
| is, but it's a smallish club and they are very pretty fonts.
| piker wrote:
| Thanks so much for the idea. You may already know this, but
| fonts are actually little pieces of software subject to their
| own licensing terms. For that reason, Tritium (like most word
| processors, I believe) relies on the system fonts available for
| rendering. Those are already owned by the user. I'll reach out
| to Matthew and see if there's any possibility for
| collaboration.
| notpushkin wrote:
| The letterforms themselves, on the other hand, might be
| uncopyrightable, depending on the jurisdiction. But paying
| for the fonts you use is just common decency - especially if
| used in a commercial product.
| benn0 wrote:
| Congrats on the launch, really great stuff. As a software
| developer who has been studying (very slowly) a law degree, I can
| really see how products like that improve existing processes can
| really fill a need. I've also seen some former colleagues gain a
| lot of traction in a very similar legal process improvement
| space.
|
| For a completely unrelated use case, I've started using it as my
| docx viewer on Linux, and so far it's been great (and solves one
| of my pain points moving from MacOS).
| gazpacho wrote:
| I like the idea! I wish I could use git / PRs to do rounds of
| edits on legal documents instead of whatever Word's track changes
| is.
|
| Speaking of, could we start using version control for keeping
| track of laws and updating old laws? It seems to me like a much
| better system than randomly burying in a new law that it strikes
| out some text from an old law.
| socks wrote:
| Reminds me of this old HN thread:
| https://news.ycombinator.com/item?id=4353389
| ppyyss8 wrote:
| I think a more user-friendly UX would really enhance the
| experience. The idea is fantastic, and I truly believe it's going
| to do well!
| hiAndrewQuinn wrote:
| Ha, I had the same thought a while back along a slightly
| different vector (legal-adjacent technical writing). I ended up
| writing a blog post of my wishlist of features Word has that
| static site generators like Hugo don't appear to, yet. [1]
|
| I think there's a lot of money to be made in this arena,
| especially given that LLMs are much easier to integrate with
| plain text files than with Word documents.
|
| [1]: https://hiandrewquinn.github.io/til-site/posts/things-
| word-h...
| WorldMaker wrote:
| Much (but not all) of what you are looking for exists in the
| reStructuredText [1] space. Sphinx [2] is an SSG focused on
| technical writing about software that you may find worth
| exploring.
|
| Also, the scientific text community has been pushing MyST [3]
| which is an attempt to take some of the best ideas of
| reStructuredText and reapply them to Markdown-style syntax as a
| baseline. The MyST tools are a lot more recent and don't have
| the maturity just yet of Sphinx (including the larger ecosystem
| such as SaaS hosts like readthedocs).
|
| [1] https://docutils.sourceforge.io/rst.html
|
| [2] https://www.sphinx-doc.org/en/master/index.html
|
| [3] https://mystmd.org/
| anduril22 wrote:
| Former attorney, now dev - sorry but hard pass on this. Lawyers
| (especially those in big law) hate using Google Docs because it's
| too dissimilar to Word.. This is leaps and bounds different. The
| Steve Jobs mantra of customers not knowing what they want applies
| in a consumer scenario, not an enterprise / business scenario
| (where lost time / retraining = dollars lost).
|
| I wish developers would think more as users and not "what would I
| like" more. I'm also pretty sure that I could count on one hand
| the number of lawyers that use Linux for any legal work.
|
| There have been a few attempts to use diffing to solve redlining,
| you should look into why they have failed.
| piker wrote:
| It's not for everybody, but it's already being used by lawyers,
| and I'm one myself and want it. Appreciate it's not for you!
| nbgoodall wrote:
| IANAL but this looks great! Congrats :)
|
| My pottery teacher runs a law firm though, I'll show it to her.
| Do you know if there are many differences in workflow or
| terminology between the US and UK?
| piker wrote:
| Actually I'm based in the UK and can say corporate law practice
| is nearly identical. Thanks for sharing!
| chrismorgan wrote:
| If you want people to use it on the web: do not under _any_
| circumstances use the pure-canvas approach. You _must_ use real
| DOM, or it will be an endless frustration that turns many people
| away. I've written about the problems quite a few times, look
| through
| https://hn.algolia.com/?type=comment&query=chrismorgan+pure+...
| if you're interested. If you're not intending it to be used via
| the web, don't worry.
|
| But it's a general principle: the more you are implementing from
| scratch, the more of a mess you're likely to be in. As one
| example, at IME is completely broken, completely preventing a
| _lot_ of non-English usage. Even my Compose key is broken: the
| key sequence `Compose - >` should produce -, but instead
| produces "Compose->". This is the first time I've seen the
| Compose key turn into the word "Compose"!
|
| For serious desktop-style applications, I honestly recommend that
| you not use plain-Rust GUI just yet. It is definitely steadily
| getting there, and I'm very optimistic that there will be at
| least two reasonable choices available within three years, but
| it's still not where I'd want it to be for an app like this yet.
| Web browsers are, unfortunately, typically the pragmatic choice,
| even for desktop-only apps.
| piker wrote:
| It's a great point. This uses the canvas element only because
| it's rendering in the browser. But this is really a desktop
| application, so the canvas element doesn't come up as a concept
| outside of WASM. Your main contention seems to be that nobody
| other than web browser implementers can render and edit text,
| and thus we should be limited to the set of applications that
| can run on the DOM and leverage the web browser's shaping and
| layout engines.
|
| There are issues solved by the DOM for sure, but it requires
| shipping an entire web browser, and this product is a dedicated
| word processor. I'd rather face those issues head-on than defer
| to someone else's implementation of such a core aspect. I know
| IME is broken, and Tritium's really only able to address the
| needs of the happy path at the moment, but if can do that well,
| then there's a business model to fund solving the edge cases to
| bring a real Word competitor to the desktop for lawyers.
| wiseowise wrote:
| > but it requires shipping an entire web browser
|
| That's a moot point and completely irrelevant for 99.99%
| people.
| piker wrote:
| Perhaps that is an accurate percentage, but lawyers are in
| that .01%. If you're competing with Microsoft Word on
| performance you'd better be stupid fast and lightweight.
| Transactional lawyers routinely have dozens of Word
| documents and PDFs open at a time. Not long-term viable
| with something like Electron.
| lionkor wrote:
| Isn't word really slow and also implemented as a web
| browser currently?
| piker wrote:
| Not the version currently used by corporate lawyers, no.
|
| I can't speak to the future, but let's say I hope so!
| rafram wrote:
| Word for Windows is fast and native. Word for Mac is
| slow, but still native.
| cAtte_ wrote:
| VS Code, the aforementioned very performant Electron-
| based IDE, would like to differ
| piker wrote:
| I'm not sure I agree it's "very performant", but
| nonetheless I do love it. (Compare it to Zed, for
| example.)
|
| In any event, VS code is only required to render text in
| a single font, with very few layout concerns, styling,
| run-level formatting, etc. that require re-flowing across
| multiple of pages, etc. And each of those is text files
| measuring in the bytes. Tritium, by contrast, has to hold
| and operate on PDFs and Word documents each with very
| complicated layout and rendering logic and measuring in
| the kbs.
| cosmic_cheese wrote:
| VS Code is very much a special case and not the least bit
| representative of the typical Electron app. It benefits
| from having some of the best talent available working on
| it and has multiple bits that drop down to lower-level
| solutions to improve performance, both of which Microsoft
| is willing to pay for because VS Code entrenches them in
| the software development world in ways it wouldn't be
| otherwise.
| wiseowise wrote:
| > has multiple bits that drop down to lower-level
| solutions to improve performance
|
| Such as?
|
| > VS Code is very much a special case and not the least
| bit representative of the typical Electron app.
|
| And Obsidian, and Discord, and Logseq, and Notion, and
| Figma, and Slack, and Postman, and Insomnia, and so on,
| and so. Oh wait, so it's not only VS Code?
| cosmic_cheese wrote:
| > Such as?
|
| At minimum it uses ripgrep for file searching, which is
| written in Rust but I thought I read blog posts about
| other parts in the past.
|
| > And Obsidian, and Discord, and Logseq, and Notion, and
| Figma, and Slack, and Postman, and Insomnia, and so on,
| and so.
|
| Out of the mentions in that list I've used, only Obsidian
| feels comparatively responsive to VS Code. Notion and
| Slack in particular are slow and can get super bogged
| down. Discord and Figma sit somewhere in between.
| ezst wrote:
| People praising VSCode's performance are probably better
| defined by having too fast computers than anything else,
| by all measures VSCode really isn't particularly
| lightweight nor performant.
| trinix912 wrote:
| It is definitely not as performant as Word on 5+ year old
| hardware that can barely run Windows 10, that many
| companies will happily order tons of.
| fl0id wrote:
| Word has the worst performance ever. So I don't think
| competing with Word on performance should be hard.
| trinix912 wrote:
| Not necessarily. You can have dozens of Word instances
| open and it still doesn't bog the system down nearly as
| much as 5 Notions with the Chromium renderer. Word might
| not seem fast, but it's lightweight enough to work on the
| crappiest PCs you (or the IT dept) can find.
| miki123211 wrote:
| > thus we should be limited to the set of applications that
| can run on the DOM and leverage the web browser's shaping and
| layout engines.
|
| Yes, if you want to run in the web browser, use the APIs the
| browser gives you. If you want to go wild, run directly on
| desktop OSes.
|
| Web browsers just straight up don't have some of the APIs you
| will need for a working app. Accessibility is a major
| example. If you want to stay compliant with legislation
| (probably something to care about when selling to lawyers),
| you'll end up poorly re-implementing an inferrior version of
| your GUI framework as a DOM tree for accessibility.
|
| Sometimes your use case is just so uncommon and esoteric
| that's genuinely what you need to do (see Google Docs), but
| keep in mind that it requires Google-like levels of
| engineering investments to do it at least somewhat well.
| piker wrote:
| Very true! That's why this is just a "web preview". It's
| not intended to be used as the primary application. As
| mentioned elsewhere, the primary application is a desktop
| application that does look to leverage native APIs that
| aren't available on the web.
| rapnie wrote:
| Build it on Makepad, who are building the UI framework (blew
| me away first time I saw it in action). Leaves you to build
| the app.
|
| https://makepad.nl
|
| https://github.com/makepad/makepad
| gwbas1c wrote:
| I for one appreciate the "no html" approach.
|
| That being said, if this is _truly_ a desktop application,
| why waste time making it run in a browser? _If the point is
| to have a preview,_ put the time into making some good short
| videos that can go into a preview page.
| piker wrote:
| Because it's cool to get your hands on something before
| diving in. Also it allows users in walled off corporate
| environments to preview it without having to jump through
| thousands of hours of infosec hurdles.
| connicpu wrote:
| Considering it's just the desktop application being
| rendered to a canvas, I imagine not a ton of effort even
| needed to be put in and the UI framework is handling most
| of it.
| cryptonector wrote:
| > Your main contention seems to be that nobody other than web
| browser implementers can render and edit text,
|
| I took it as a claim that using the canvas you can't
| implement _inputs_ correctly. The example given was about
| compose sequences, but I'm sure there's much more to it.
| hitekker wrote:
| Yeah the GP's reply was a little misleading/ambiguous. It
| begins by saying "great point" but then it distorts &
| argues against that point.
|
| Better just to disagree directly, I think.
| cryptonector wrote:
| Maybe u/piker misunderstood u/chrismorgan's point.
| z3t4 wrote:
| You do get a lot for free with the DOM, but it's messy, works
| differently between different browser and you have to
| constantly fight it. With your own rendering engine it's more
| work but you have much more freedom and can get better
| performance.
| panzi wrote:
| With DOM you get accessibility integration. At least in the
| EU if you provide a web service you have to be accessible,
| otherwise you can get sued.
| z3t4 wrote:
| IANAL,afaik the accessibility law is only for government
| monopoly services. But I don't think it matters, because if
| you use the DOM you still need to test if the app works in
| screen readers etc, even normal websites have trouble with
| accessibility.
| panzi wrote:
| AFAIK it applies to everyone. But you don't get
| automatically fined, someone has to sue first. Maybe
| there has to be a business relation between the user and
| the web site? And yes, with HTML you need to still use
| all the right tags and attributes to make it accessible.
| Firefox has a nice accessibility tree view in its dev
| tools that you can use for debugging. Is there something
| like that for this toolkit? Is it somehow exposing an
| accessibility tree? Replicating everything in DOM for
| accessibility?
| eviks wrote:
| Wait, which 2 do you expect to become usable?
| chrismorgan wrote:
| It might not be particularly visible from outside just yet,
| but we've reached the stage where a lot of the fundamentals
| (which are typically deplorable in quick-and-dirty libraries)
| _really are_ being nailed down quite nicely; and, perhaps
| more importantly, where a lot of the different teams are
| sharing work and collaborating on libraries, rather than each
| project starting from scratch. The momentum around AccessKit
| is the most visible example of this.
|
| The Linebender community is a very promising venue for such
| collaboration, and there are at least four organisations
| investing quite a bit into this and related endeavours.
|
| I won't name any specific two libraries. It also depends a
| little on whether you're targeting web tech only, or web and
| desktop, or desktop. (Or mobile.)
| ModernMech wrote:
| The way this app is architected with Rust and egui, they can
| write code once and deploy a GPU accelerated app across all
| major operating systems and the browser, without having to ship
| a web browser with their application. That's a strong draw for
| developers. I think it's important to ship products like this,
| even if some users are frustrated, because that frustration
| will breed innovation. Since they said it's meant to be desktop
| only, I think what they're doing is fine, as the web is just an
| added bonus.
|
| The approach they've taken can create frustration, but it can
| also be seamless for users and create joy. For instance, I got
| to try out their app without any setup on my part, and then I
| can download it and it works exactly the same on my Windows and
| my Mac machines, because it's the same codebase for all three
| platforms. That kind of story was the holy grail of UI tooling
| for many years, and I think we should keep going down that path
| to improve it, despite frustrations along the way.
| a_e_k wrote:
| This is explicitly called out in the canvas spec's best
| practices section with a laundry list of things you'd have to
| re-implement [1].
|
| > Authors should avoid implementing text editing controls using
| the canvas element. Doing so has a large number of
| disadvantages:
|
| > [...]
|
| > This is a huge amount of work, and authors are most strongly
| encouraged to avoid doing any of it by instead using the input
| element, the textarea element, or the contenteditable
| attribute.
|
| [1] https://html.spec.whatwg.org/multipage/canvas.html#best-
| prac...
| dtj1123 wrote:
| One thought regarding footnotes. I often find myself searching in
| the reverse direction, i.e. I have a footnote, where is the
| superscript to which it belongs?. This is quite difficult to do
| by eye, so perhaps some goto reference type functionality could
| be useful in this case.
| piker wrote:
| Great idea! Definitely coming.
| n_plus_1_acc wrote:
| Trivial in LaTeX, does word not do that?
| gamblor956 wrote:
| There have been Word add-ons that do all of this for a while now,
| specifically targeted at lawyers.
|
| Why would a law firm give up Word for this? That's your
| competition and unlike techies they're not going to waste time on
| an MVP, they want and need a finished product.
| piker wrote:
| Because the add-ins are crap and they know it. But you're
| right: the risk here is purely technical.
| piker wrote:
| I've added a very simple demo request page for folks who want to
| try Tritium at work: https://tritium.legal/demo.
|
| I'd love to run a demo for you or your legal team.
| WolfOliver wrote:
| I was wondering why the creation of docx files does not seem to
| have any formatting options but just plain text? Is this not
| required in legal context?
| piker wrote:
| It actually does on the desktop versions. The "web preview"
| doesn't have any access to the browser's fonts, so it's limited
| to an open-source embedded font. Check out the downloads!
| lionkor wrote:
| Hi, good to see you respond to criticism here, too. Personally, I
| can't try it locally right now, and the web demo refused to load
| on Firefox. On Chrome, it loaded, but it's... very slow to load
| files when I click on them, and there is a visible delay between
| taking an action and seeing that action reflected in the demo.
|
| I bet this is a WASM limitation, I work with WASM and with Rust
| every day (though sadly not related lol), so I know the pain to
| some extent. Just please but a banner at the top saying "This
| preview has limited performance and responsiveness. The native
| app doesn't have these limitations and can be downloaded here:
| <link>", or similar (assuming you are aware of serious
| performance limitations in the browser. If not, and if your
| native app performs the same, please use profilers to figure out
| whats wrong).
| piker wrote:
| Thanks so much. It does have this banner: "Some features are
| unavailable in Web Preview. <link>Download the Desktop
| version</link> for full speed and functionality." which is
| intended to capture that exact issue.
|
| I'd love to coordinate a demo for you personally if you can
| spare the time. I'm at drew@tritium.legal or you could drop
| your info here: https://tritium.legal/demo. I'm familiar with
| working with and onboarding to regulated IT departments.
|
| [NOTE: some of the speed issues are coming from the pipes
| clogging up due to the traffic. There's no CDN here
| unfortunately.]
| truekonrads wrote:
| Hi! Tech/cyber person at a law firm here. Major concern I can see
| is "will this make the formatting go haywire"? Also which kinds
| law practice groups would benefit them most. Finally - how can
| this be collaborative ?
| piker wrote:
| The promise is what you see is what you get between Word and
| Tritium [desktop].
|
| Transactional practices like RE, funds, capital markets,
| finance, derivatives, M&A are the target audience.
|
| The roadmap includes a shared history but iManage integration
| is also in the works. So the experience will target google-docs
| like collab with something more familiar in terms of version
| control. That's on the roadmap though.
|
| Can we chat offline? drew@tritium.legal
| jeroenhd wrote:
| I don't know what sort of bug this is, but if I try the preview
| in Firefox on macOS and hit ' or " the editor inserts the word
| "Dead". It looks like the editor is using ctrl+z on macOS which
| is... a choice. On the other hand, at least it seems to treat the
| home/end keys normally, which is infuriatingly hard to make macOS
| do.
|
| That's probably a dead key issue (one reason custom renderers for
| web applications are so tedious to program) but I find it very
| funny to have a dedicated "Dead" key. Useful for people dealing
| with wills a lot, I suppose!
|
| Edit: same is true for Chrome, so it's probably a Tritium issue
| and not a browser issue...
| piker wrote:
| Awesome bug report! Thank you. Let me check into it. Would be
| even better to understand if you could replicate it on the
| Desktop application.
| artursapek wrote:
| This is really cool. I've recently also had an observation about
| the modern lawyer's toolset: they have no idea what version
| control is. Lawyers email around countless duplicate copies of
| .docx files as their version control. "Red line" files only hold
| a single revision. This can definitely be improved upon.
| flkiwi wrote:
| It just warms my heart to see so many lawyers pining for git-
| based change management and drafting-as-code all in one place. I
| KNEW I WASN'T ALONE.
| bernstml19 wrote:
| I created an account just to marvel at this very concept
| brudgers wrote:
| _I 'm excited for the prospect of lawyers running Linux as their
| daily driver_
|
| This does not benefit your customers in any way.
|
| It does not benefit their clients, either.
|
| And brain activity around it is a distraction from what your
| business does.
|
| At best.
|
| Good luck.
| piker wrote:
| That's a fair take at surface level, but building a cross-
| platform application does allow for a broader class of
| contributors who can also dogfood the product.
|
| I'll have to do another write-up about it sometime, but a lot
| of Tritium's automated tests are written in docx files. So
| building for Linux as an afterthought allows an employee to
| develop from their preferred platform (if it's Linux) while
| still getting the full experience. Also there is something
| quite informing about discovering differences between platforms
| that help you to better understand the capabilities of each.
|
| I also do believe one day we'll see, e.g., crypto startups'
| lawyers using Linux. And they'll be happy Tritium customers :)
| brudgers wrote:
| If your target customers care about linux and rust, you have
| probably over segmented the market.
| piker wrote:
| Yeah, that's true - they really don't. But it helps with
| the DDQs when you can tell their Infosec people that it's a
| typesafe language. In the end it's another bullet point but
| not much more. It's great to be able to run it on Linux and
| develop in Rust though.
| bernstml19 wrote:
| What's wrong with MS Word again?
___________________________________________________________________
(page generated 2025-06-13 23:01 UTC)