91–100 of 132 posts
I hope this law applies to all of the Electron applications out there...
I hope this law applies to all of the Electron applications out there...
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.
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…
At some stage, I expect that we will know what is the set of "optimal" computer languages for the interface between the programmer and the machine code.
Natural languages can't really capture the lower-level details of a program, but there's (probably) also no need for all N different ways to write a for loop.
Earlier quoted context omitted.
What does the struggle with an LLMs help look like?
"Explain this to me" until you're able to complete the task, instead of "do this for me"
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.
Earlier quoted context omitted.
Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.
Idk. Did you see the "Buffer reuse" section of this blog post? [1] Kudos to that guy for solving the puzzle, but I really don't want to use a special trick to get the compiler to let me reuse a buffer in a for loop. [1]: https://davidlattimore.github.io/posts/2025/09/02/rustforge-...
I also don't fully understand the buffer reuse example. Why would you want to store references to a string after the string ceases to exist?
Earlier quoted context omitted.
Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.
This is a n objectively false statement. Rusts borrow checker is only able to prove at compile-time that a subset of correct programs are correct. There are many correct programs that the BC is unable to prove to be correct and therefore rejects them. I’m a big fan of Rust and the BC. But let’s not twist reality here.
No. The borrow checker rejects programs that are definitely incorrect. It does not require that the program is correct.
That's a big difference.
Earlier quoted context omitted.
You might wonder that if you just read the headline. But, if you read the article, the reasons given for rust in particular are reasonable, and not matched by assembly or machine code.
If you read the article you'd know they were talking about go/rust. We can sprinkle bugs with borrow checker to burn them in Rust, fair enough everyone knows that the only bugs that happen in system languages are memory errors. But what's the holy water we can use to banish bugs in Go?
But go is memory managed and statically typed, and, obviously, assembly language or pure binary opcodes aren't.
The article certainly isn't perfect, but the thesis wasn't just that "Hey, LLMs can now write stuff for us in more efficient languages."
It was (rightly or wrongly) that LLMs can let us more easily use more complicated languages that both go faster and do more checking than most dynamic languages.