Rust, Python, and TypeScript: the new trifecta

15 nromiun 17 8/5/2025, 10:13:23 AM smallcultfollowing.com ↗

Comments (17)

benterix · 5h ago
> And TypeScript of course runs natively on browsers

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.

DanielHB · 3h ago
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.
tmaly · 40m ago
This would actually be amazing if it were true.
beardyw · 5h ago
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.

pjmlp · 4h ago
Actually if efficiency is paramount, Assembly would be the right answer.
Tohsig · 5h ago
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.

papichulo2023 · 5h ago
I didnt like Go verbosity before. Now I enjoy it way more since the llm generates it.
machiaweliczny · 3h ago
Speed and typing will win. TS and Go will be dominant in LLM assisted code.
robviren · 5h ago
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.

pjmlp · 4h ago
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.

sshine · 1h ago
> 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.

pjmlp · 1h ago
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.

misja111 · 6h ago
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.

SkiFire13 · 5h ago
> 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.

sshine · 6h ago
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!")

eulgro · 6h ago
Which begs the question: what was the old trifecta?
garyfirestorm · 2h ago
java vb.net c/c++ /s