Rust, Python, and TypeScript: the new trifecta(smallcultfollowing.com)
smallcultfollowing.com
Rust, Python, and TypeScript: the new trifecta
https://smallcultfollowing.com/babysteps/blog/2025/07/31/rs-py-ts-trifecta/
32 comments
There are some proposals for browsers to do type-stripping, removing/ignoring type-annotations so typescript (and flow) don't need transpilation anymore (except for enums I guess). NodeJS already started doing that in the latest version as well.
Direct link to the Stage 1 proposal: https://github.com/tc39/proposal-type-annotations
Thanks, interesting that there are a lot more typescript things that wouldn't be covered by the proposal besides enums (class/fields modifiers, function overloading, declare keyword, namespaces).
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).
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).
Typescript has had the "erasableSyntaxOnly" compiler option for a couple versions now. Running it on a medium sized or large code base isn't terrible. With Node now supporting type-stripping, you can run entire large code bases without compilation today after that flag, so there's some benefit to doing it. (If for some reason you need to support an out-of-support Typescript version, eslint has had linter rules that match "erasableSyntaxOnly" for even longer.)
> (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.
> (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.
I was just thinking of the projects I worked in and none of them would be a clean migration to not transpile typescript anymore in development mode.
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.
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.
This would actually be amazing if it were true.
And
>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.
>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.
Actually if efficiency is paramount, Assembly would be the right answer.
That only gets you efficiency on one system, as dictated by microarchitecture.
You are observing the rules to write efficient code, correct?
You are observing the rules to write efficient code, correct?
It gives more than C, as the days of it being a portable high level assembly are long gone.
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.
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.
Python and Typescript/JavaScript I largely agree. Those languages frequently top the list of most used languages with probably the most code represented in the popular foundation models. Even though Python has shifted over time the sheer number of examples models have access to makes it more robust than most other languages.
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.
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.
> Guaranteed backwards compatibility
Cough loop iterator semantics changes uncough
Cough loop iterator semantics changes uncough
I suspect it's too early to make predictions about which languages are going to become dominant moving forward, but in my experience robust type systems do seem to improve the accuracy of responses that I get from the various LLMs. I've been writing JS/TS for over a little over a decade now and am regularly impressed with what the best of the current crop of models can turn out. I'm not just seeing decent TS code but also decent explanations as to why the model went one direction vs. another. I'm sure that's at least partially thanks to the sheer quantity of JS/TS code that's out there.
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 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 didnt like Go verbosity before. Now I enjoy it way more since the llm generates it.
Speed and typing will win. TS and Go will be dominant in LLM assisted code.
Have you used `usage_rules` yet?
Pity that TypeScript team decided to rewrite its implementation in Go, and there are no plans in sight to rewrite V8, thus C++ addons keeps being the easiest way to extend it.
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.
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.
> As for Rust, I don't have a use case at work where it is a win over managed compiled languages
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.
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.
Nothing of that is a sales pitch for me.
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.
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.
>Nothing of that is a sales pitch for me.
Just imagine the case, when you may save on a cloud several hundred thousand dollars per year just choosing more effective programming language.
Just imagine the case, when you may save on a cloud several hundred thousand dollars per year just choosing more effective programming language.
Well, thanks for the flashback.
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.
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.
When AI becomes even more mature, traditional languages will lose their market position, it is the assembly developer job being replaced by optimizing compilers in high level languages of yore.
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.
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.
The author is overlooking the need for enterprise server software that needs to be safe, stable, extendable to large systems and easily maintainable above anything else.
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.
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.
Rust is not only about ownership or ints with specific bit lengths. It is about powerful type system which is quite important in business logic (if you have enough knowledge to use it properly).
[deleted]
> ints with specific bit lengths
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).
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).
> 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.
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.
I've vibe-coded TypeScript and Rust with great success.
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!")
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!")
Good article, I am in full agreement
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.