81–90 of 132 posts
> in 2026 devs write 90% of the code using natural language, through an LLM. That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)? If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with. I literally cannot imagine a serious company in which that is a viable scenario.
Why not go? Slower than rust. Type system is lacking.
Why not c? Not memory safe.
Why not c++? Also not memory safe.
Why not zig? Not memory safe.
Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors.
Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.
Earlier quoted context omitted.
This seems like a really short-sighted view. 6 months from now you'll be much more inexperienced than if you just went through the initial struggle (with an LLM's help!)
What does the struggle with an LLMs help look like?
Why not assembly? Not enough compile time checks, only runtime errors. Why not go? Slower than rust. Type system is lacking. Why not c? Not memory safe. Why not c++? Also not memory safe. Why not zig? Not memory safe. Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors. Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.
That’s not a bad thing though. It’s okay to aim for your thing and be good at just that. No need to try to please everyone.
Why not assembly? Not enough compile time checks, only runtime errors. Why not go? Slower than rust. Type system is lacking. Why not c? Not memory safe. Why not c++? Also not memory safe. Why not zig? Not memory safe. Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors. Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.
Rust isn’t versatile enough to be used in high-level contexts. You simply have to jump through too many hoops. It’s great for low-level apps but if I just want a simple UI and CRUD functionality, I’m reaching for C#/Kotlin. That’s not a bad thing though. It’s okay to aim for your thing and be good at just that. No need to try to please everyone.
Why not assembly? Not enough compile time checks, only runtime errors. Why not go? Slower than rust. Type system is lacking. Why not c? Not memory safe. Why not c++? Also not memory safe. Why not zig? Not memory safe. Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors. Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.
Why not assembly? Not enough compile time checks, only runtime errors. Why not go? Slower than rust. Type system is lacking. Why not c? Not memory safe. Why not c++? Also not memory safe. Why not zig? Not memory safe. Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors. Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.
Why not assembly? Not enough compile time checks, only runtime errors. Why not go? Slower than rust. Type system is lacking. Why not c? Not memory safe. Why not c++? Also not memory safe. Why not zig? Not memory safe. Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors. Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.
So, I am then interested in non trivial software written with LLM assistance and in Rust. Off the top of my head I'm aware of Turso (supposed sqlite successor), marketing approach aise, I find it interesting to see how that works out. Any others?
If LLMs live up to their potential, then they should be able to rewrite language runtimes to eventually be as fast or faster than systems languages. "Sufficiently intelligent compiler" and whatnot
To steelman your argument, the only case I can see that it is not true is the case where the compiled output is not strictly the fastest solution possible. In that case through I can see the very same LLM just generating significantly better code for in the compiled language.
Given infinite memory all problems can be boiled down to O(1), the reality is that that is unlikely to happen because resources are finite and if there is such a hot path in code you can find it an perform the relevant operations in a compiled language, you can also imply an LLM given access to the runtime metrics.
The thinking that the runtime can solve the problem (cache the correct solution to a dynamic problem) is directly at odds with modern infrastructure that treats services and ephemeral and just kills them. I imagine every time you git push and your CD pipeline runs it ou have a large factor performance degradation for the first X thousands queries.
I kinda like viewing this as similar to coordinate-invariance in physics / geometry. A programming language is effectively a function from textual programs to behaviors; this serves the same role as a coordinate system on a space, which is a function from coordinates to points. Naturally many different programs and programming languages can describe the same behavior, especially if you forget about implementation-spe…
I imagine those languages will be left by the wayside.