Rust, Python, and TypeScript: the new trifecta
smallcultfollowing.com
smallcultfollowing.com
As a backend engineer I was thinking, "Whoah, the frontend is moving so fast that browsers support Typescript natively!" But it turns out the author is either uninformed, or, more likely, just being sloppy.
>Rust targets system software or places where efficiency is paramount.
Well, if that's all you want you could use C!
Maybe it's written by AI.
You are observing the rules to write efficient code, correct?
Plus for those that love their pre-processor, proper macro assemblers are quite powerful, unlike those UNIX assemblers that were designed to be used as part of C compilation pipeline with very few amenities.
Meaning the proposal would only really be useful for fairly small projects. It would be nice to have bundlers not need to do any transpilation at all while in dev mode, but this will not get us 100% there (even for non-JSX projects).
> (class/fields modifiers, function overloading, declare keyword, namespaces)
Most of the class/field modifiers have standard JS ways to do them today (#field for private, [symbolField] for protected/"internal"). The nicest one to have and hardest to replace is `readonly` used to enforce at compile time that a field is only ever set once at initialization. There are workarounds with properties and property syntax and a workaround to use a JSDoc comment.
Function overloading and declare keyword can generally be handled by moving everything to an appropriate .d.ts file. Also a lot of function overloading can be taken care of today in more JS-friendly ways with union types or `unknown` with type guards that better matches the runtime experience of JS. (I realize that there are definitely still edge cases that can be easier to write as function overloads than as `unknown` with type guards, but they seem so much fewer than ever.)
I personally have only found one use case for namespaces in a while that isn't solved with module (re-)architecture (including "exports" at the package level architecture) and/or symbol-named things. That use case is silliness involving passing JSX type information. Typescript is a little weird about how it wants to pick up JSX types. It should still work in a .d.ts and that's on my TODO list of things to try soon (I'm working on a rewrite of a JSX-based view engine where one of the motivations for the rewrite is to get possibly really wild with JSX types because moving from one `jsx` function to many, for interesting reasons).
I know the "gentle merge" of namespace will be missed by some, but the code it generates is easy to reproduce in pure JS and will be very familiar to anyone who did a lot of jQuery era `window.myObject = window.myObject || {}` dances, which were the style at the time and that to get that to type how you need it to you'll need a lot more `as unknown as MyExtendedObject` type dances. But also that's a somewhat better type representation of what you are doing with those sorts of multiply expanded objects.
My main problem would be the typescript class/field modifiers, like you said I use readonly extensively. I didn't know about the "erasableSyntaxOnly" compiler option, I will make sure to turn it on for newer codebases.
I am less convinced Rust belongs in the list. Rust is far behind the number of examples the large models have access to, the syntax is fairly ham handed, and I don't feel the library story is as strong as with python (though probably on equal footing with JavaScript). My two cents on Rust and LLM compatibility.
If I had to add a third I would pick Go. Guaranteed backwards compatibility, robust and frequently used standard library, rigidly enforced format, and a wonderful type system. Though I actually don't know that for training purposes having perfectly formatted code is actually a good thing. Ironically a more pythonic coding where you can kind of do whatever stretches the models understanding better making it more robust, from what I understand.
Cough loop iterator semantics changes uncough
I contrast that with the responses I get back from the LLMs for Elixir. I'm currently learning Elixir/Phoenix/Ash for a personal project. Absolutely loving that environment, but I'm seeing a much lower level of accuracy from the models. Basic questions about Elixir syntax and best practices are usually fine, but with anything more complex the responses are often more of a hinderance.
Phoenix, Ash, and Elixir itself are so well documented that the inaccurate LLM responses aren't slowing me down overall, but I'm very curious about whether the underlying issue has more to do with Elixir itself or just the amount of sample code that's in the wild.
I have no plans to adopt Python beyond OS scripting tasks, even in the context of AI, other ecosystems are starting to have bindings to the same C++ libraries.
As for Rust, I don't have a use case at work where it is a win over managed compiled languages, maybe if Vercel finally offers first class support for it, instead of the community runtime or via WebAssembly.
So maybe it is a new trifecta for some users, not all of us.
EDIT: Additionally, I think AI will make current languages largely irrelevant, as they increasingly get better at code generation.
Very performant, very easy to distribute cross-compiled static binaries, very portable to web, embedded, anywhere.
The main downside of Rust, being that it has a high learning curve and is costly to write in because of all the training, could be less and less of a problem.
Compiled managed languages are fast enough for all kinds of workloads I work on.
Also I am polyglot since the days of Timex 2068, so a little bit of FFI isn't an issue. No need to throw away the productivity tooling of the baby with the water.
Finally, as someone coding since the 8 bit home computer days, the religious discussion of static linking belongs into the same basket as using an i9 with a NVidia RTX to power a UNIX System V like command line experience, or reliving the glory days of curses, Clipper, FoxPro or Turbo Vision applications in 2025.
One can get too obsessed about performance.
Productivity with AI-generated Rust should be on par with anything since the verbosity is only measured in tok/s.
I am already aware of at least one project where the contractor was doing the required assignment in a Python prototype, and then the client team used AI tooling to convert it into Go for the actual production code.
Even this, will be more for debugging purposes, as nothing prevents to use the same prompts to eventually generate Assembly or machine code directly.
Sure, LLMs are still a bit buggy for that in 2025, nonetheless not imagining how programming will look in 10 years time, with the hindsight that we are only at this AI hype cycle for two years, will be the failure of those that can only identity themselves with being a technology XYZ developer.
Just imagine the case, when you may save on a cloud several hundred thousand dollars per year just choosing more effective programming language.
None of his three languages fits that bill. Python is not (type) safe enough. Typescript is meant for running in browser. And Rust, although it has a good type system, is meant primarily for system software. Compared to garbage collected languages such as Java, it loses on maintainability and extendibility because you don't want to be bothered with stuff like data ownership or ints with specific bit lengths in large systems that need to deal only with business logic.
Java also has integer types with different bit lengths, you just don't have that length in their names which makes them harder to understand.
Your LLM is perfectly capable of using https://docs.rs/num/latest/num/struct.BigInt.html or such as needed. Yeah it's not part of the language but many many things in Rust aren't (intentionally).
I've vibe-coded Haskell to great disappointment.
I just can't accept how verbose and ugly it gets.
Which, for some reason, I'm totally okay with when coding Rust and TypeScript.
I mean, I obviously aim for simplicity and will refactor and simplify things.
But I don't hugely care about a few extra lines or indentation levels.
I just care that it breaks formatters all the time; I have a pre-commit hook that runs the formatter at this point, so I only need to repeat the commit command once after adding the formatting diff. Feels like I should make it run the formatter every time it completes something, but I'm not sure how to make it consistently do that (I must remember to initialize every time by saying "Here's your CONTEXT.md!")