This is my second attempt learning Rust and I have found that LLMs are a game-changer. They are really good at proposing ways to deal with borrow-checker problems that are very difficult to diagnose as a Rust beginner.
In particular, an error on one line may force you to change a large part of your code. As a beginner this can be intimidating ("do I really need to change everything that uses this struct to use a borrow instead of ownership? will that cause errors elsewhere?") and I found that induced analysis paralysis in me. Talking to an LLM about my options gave me the confidence to do a big change.
>In particular, an error on one line may force you to change a large part of your code.
There's a simple trick to avoid that, use `.clone()` more and use fewer references.
In C++ you would be probably copying around even more data unnecessarily before optimization. In Rust everything is move by default. A few clones here and there can obviate the need to think about lifetimes everywhere and put you roughly on par with normal C++.
You can still optimize later when you solved the problem.
I've been thinking about this and using Rust for my next backend. I think we still lack a true "all in one" web "batteries included" framework like Django or RoR for Rust.
Maybe someone should use AI to write the code for that...
I don't really want to learn how to use the borrow checker, LLM help or not, and I don't really want to use a language that doesn't have a reputation for very fast compile/dev workflow, LLM help or not.
Re; Go, I don't want to use a language that is slower than C, LLM help or not.
Zig is the real next Javascript, not Rust or Go. It's as fast or faster than C, it compiles very fast, it has fast safe release modes. It has incredible meta programming, easier to use even than Lisp.
Predicting the future is futile, but I would guess this would be exactly the opposite. LLMs make it remarkably easy to generate a lot of code so they can easily generate a lot of Rust code that looks good. It probably wouldn't be, and for us it would be unreadable when something goes wrong. We would end up in LLM debugging hell.
The solution is to use a higher level safer, strict language (e.g. Java) that would be easy for us to debug and deeply familiar to all LLMs. Yes, we will generate more code, but if you spend the LLM time focusing on nitpicking performance rather than productivity you would end up in the same problem you have with humans. LLMs also have capacity limits and the engineers that operate them have capacity limits, neither one is going away.
While I still struggle to think in Rust after years of thinking in C, it is NEVER the borrow checker or lifetimes that trip me, it's the level of abstraction, in that C forced me low level, building my own abstractions, while Rust allows me to think in abstractions first and muse over how to implement those idiomatically.
What did it for me was thinking through how mutable==exclusive, non-mutable==shared, and getting my head around Send and Sync (not quite there yet).
AI helps me with boiler plate, but not with understanding, and if I don't understand I cannot validate what AI produces.
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-specific details like memory layout or class structures. LLM code generation is just another piece of the same model: turns out that to some degree you can use English+LLMs as coordinate systems for the textual programs.
I expect that over time we will adopt a perspective on programming that the code doesn't matter at all; each engineer can bring whatever syntax or language they prefer, and it will be freely translated into isomorphic code in other languages as necessary to run in whatever setting necessary. Probably we will settle on an interchange format which is somehow as close as possible to the "intent" of the code, with all of the language-specific concepts stripped away, and then all a language will be is a toolbox that an engineer carries with them of their favorite ways to express concepts.
It might be the opposite. Python apps still get written despite the performance hit, because understandability matters more than raw performance in many cases. Now that we’re all code reviewers, that quality should matter more, not less. Programmer time is still more expensive than machine time in many cases.
I use Claude Code daily to work on a large Python codebase and I'm yet to see the it hallucinating a variable or method (I always ask it to write and run unit tests, so that may be helping). Anyway, I don't think that's a problem at all, most problems I face with AI-generated code are not solved by a borrow-checker or a compiler: bad architecture, lack of forward-thinking, hallucinations in the contract of external API calls, etc.
I'm surprised the author of this article thinks Go is a "system language".
Go uses GC, and therefore can't be used for hard real time applications. That's disqualifying as I understand it.
C, C++, Rust, Ada, and Mojo are true system languages IMO. It is true that as long as you can pre-allocate your data structures, and disable GC at runtime, that GC-enabled languages can be used. However, many of them rely on GC in their standard libraries.
Why stop at a systems language? Why not assembly? Hell why not raw machine code?
You have to rewrite it for every new processor? Big deal. Llm magic means that cost isn't an issue and a rewrite is just changing a single variable in the docs.
The author makes the argument that in the age of LLMs more type safe languages will be more successful than less type safe ones. But how does that support the claim that Go is more suitable than JavaScript? TypeScript is more type safe than Go: Go doesn’t validate nil pointers, it doesn’t enforce fields to be set when initializing structs, it has no support for union types. All those things can cause runtime errors that are caught are caught at compile time in TypeScript.
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
I mean the simple answer here is to just develop proper frameworks for Futamura projections. There's an exact one to one algorithmic correspondence between an interpreted program and the compiled version of that. GraalVM and PyPy are good options here.
Using an LLM is overkill especially when correctness can never be guaranteed by systems who must sample from a probability distribution.
If you don’t understand how to do programming at this level you’re not going to get far with an LLM. They tend to fall down on anything larger than a greenfield todo app.
You can easily write slow code in C and Rust. Get enough branch mispredictions and cache misses and it won’t matter that your program is written in a low level language. Guiding profilers to optimize workloads takes more context than source code alone has. You’ll still need to know how memory is architected and how many cycles instructions take on the platform you’re targeting. And you’ll have to guide the LLM to it. It might be easier and faster to do it yourself.
An LLM can generate the kind of code that has no obvious errors in it. It’s trained on the sloppy code that unreasonable deadlines and hubris produce. Humans are notoriously bad at detecting undefined behaviour, safety, and temporal errors in single programs let alone whole systems. How is an untrained developer who hasn’t been contending with systems programming for the last twenty years supposed to review and verify this code?
You’ll need to get fast at verifying large amounts of code quickly or else pray that the LLM isn’t generating the kinds of exploitable memory bugs that lead to funny machines and RCEs. We already have enough of this code as it is and most teams are trying to be conservative with their tech debt.
I have no doubt that some amount of code will be generated by LLMs in these sorts of languages and systems. Even after the bubble pops and the feudal lords lose their ability to extract rents. But I think most people using them will be more tactical and careful in their approach. At least I hope so.
There are still many good reasons to use a high level language. And if folks want to break into systems programming that’s great! But you have to learn systems programming in order to use an LLM effectively, in my experience. There’s no shortcut.
bold but wrong. 90% of code is not written by LLM. LLMs are helpful for learning a new language for sure. CPU speed has been increasing the past few years, it's not clear we've totally hit the wall for interpreted languages. i like system languages though.
It would be nice if everything were written in Coq or Isabelle with proof so that you could generate a correct program in a systems language from it. The proof checker is much more ruthless than the rust compiler.
27 comments
[ 4.4 ms ] story [ 55.7 ms ] threadIn particular, an error on one line may force you to change a large part of your code. As a beginner this can be intimidating ("do I really need to change everything that uses this struct to use a borrow instead of ownership? will that cause errors elsewhere?") and I found that induced analysis paralysis in me. Talking to an LLM about my options gave me the confidence to do a big change.
There's a simple trick to avoid that, use `.clone()` more and use fewer references.
In C++ you would be probably copying around even more data unnecessarily before optimization. In Rust everything is move by default. A few clones here and there can obviate the need to think about lifetimes everywhere and put you roughly on par with normal C++.
You can still optimize later when you solved the problem.
Maybe someone should use AI to write the code for that...
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.
Re; Go, I don't want to use a language that is slower than C, LLM help or not.
Zig is the real next Javascript, not Rust or Go. It's as fast or faster than C, it compiles very fast, it has fast safe release modes. It has incredible meta programming, easier to use even than Lisp.
The solution is to use a higher level safer, strict language (e.g. Java) that would be easy for us to debug and deeply familiar to all LLMs. Yes, we will generate more code, but if you spend the LLM time focusing on nitpicking performance rather than productivity you would end up in the same problem you have with humans. LLMs also have capacity limits and the engineers that operate them have capacity limits, neither one is going away.
What did it for me was thinking through how mutable==exclusive, non-mutable==shared, and getting my head around Send and Sync (not quite there yet).
AI helps me with boiler plate, but not with understanding, and if I don't understand I cannot validate what AI produces.
Rust is worth the effort.
I expect that over time we will adopt a perspective on programming that the code doesn't matter at all; each engineer can bring whatever syntax or language they prefer, and it will be freely translated into isomorphic code in other languages as necessary to run in whatever setting necessary. Probably we will settle on an interchange format which is somehow as close as possible to the "intent" of the code, with all of the language-specific concepts stripped away, and then all a language will be is a toolbox that an engineer carries with them of their favorite ways to express concepts.
Go uses GC, and therefore can't be used for hard real time applications. That's disqualifying as I understand it.
C, C++, Rust, Ada, and Mojo are true system languages IMO. It is true that as long as you can pre-allocate your data structures, and disable GC at runtime, that GC-enabled languages can be used. However, many of them rely on GC in their standard libraries.
You have to rewrite it for every new processor? Big deal. Llm magic means that cost isn't an issue and a rewrite is just changing a single variable in the docs.
There's a joke I forgot its name, something goes like
- high performance language but hard-coded
- xml/yaml configs
- dynamic configs and codegen
- metaprogramming or DSL, or just lua or python
- let's static type to speed things up and use a compiler
- high performance language but hard-coded
Using an LLM is overkill especially when correctness can never be guaranteed by systems who must sample from a probability distribution.
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.
You can easily write slow code in C and Rust. Get enough branch mispredictions and cache misses and it won’t matter that your program is written in a low level language. Guiding profilers to optimize workloads takes more context than source code alone has. You’ll still need to know how memory is architected and how many cycles instructions take on the platform you’re targeting. And you’ll have to guide the LLM to it. It might be easier and faster to do it yourself.
An LLM can generate the kind of code that has no obvious errors in it. It’s trained on the sloppy code that unreasonable deadlines and hubris produce. Humans are notoriously bad at detecting undefined behaviour, safety, and temporal errors in single programs let alone whole systems. How is an untrained developer who hasn’t been contending with systems programming for the last twenty years supposed to review and verify this code?
You’ll need to get fast at verifying large amounts of code quickly or else pray that the LLM isn’t generating the kinds of exploitable memory bugs that lead to funny machines and RCEs. We already have enough of this code as it is and most teams are trying to be conservative with their tech debt.
I have no doubt that some amount of code will be generated by LLMs in these sorts of languages and systems. Even after the bubble pops and the feudal lords lose their ability to extract rents. But I think most people using them will be more tactical and careful in their approach. At least I hope so.
There are still many good reasons to use a high level language. And if folks want to break into systems programming that’s great! But you have to learn systems programming in order to use an LLM effectively, in my experience. There’s no shortcut.