9 ms·

Any application that can be written in a system language, eventually will be

105 points by almonerthis 9mo ago

deleted 9mo ago
[deleted]
n_u 9mo ago
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.
- monero-xmr 9mo ago
  I am old but C is similarly improved by LLM. Build system, boilerplate, syscalls, potential memory leaks. It will be OK when the Linux graybeards die because new people can come up to speed much more quickly
  - lmm 9mo ago
    The thing is LLM-assisted C is still memory unsafe and almost certainly has undefined behaviour; the LLM might catch some low hanging fruit memory problems but you can never be confident that it's caught them all. So it doesn't really leave you any better off in the ways that matter.
    - monero-xmr 9mo ago
      I don’t code C much, is my passion side language. LLM improves my ability to be productive and quickly. Is not a silver bullet, but is an assist
    - tomrod 9mo ago
      Almost as well as a human doing it!
      - lmm 9mo ago
        Better than a human maybe. But still not good enough to rely on.
- pfdietz 9mo ago
  I don't see why it shouldn't be even more automated than that, with LLM ideas tested automatically by differential testing of components against the previous implementation. EDIT: typo fixed, thx
  - n_u 9mo ago
    I'm assuming you meant to type > I don't see why it *shouldn't be even more automated In my particular case, I'm learning so having an LLM write the whole thing for me defeats the point. The LLM is a very patient (and sometimes unreliable) mentor.
  - happytoexplain 9mo ago
    Defining tests that test for the right things requires an understanding of the problem space, just as writing the code yourself in the first place does. It's a catch-22. Using LLMs in that context would be pointless (unless you're writing short-lived one-off garbage on purpose). I.e. the parent is speaking in the context of learning, not in the context of producing something that appears to work.
    - pfdietz 9mo ago
      I'm not sure that's true. Bombarding code with huge numbers of randomly generated tests can be highly effective, especially if the tests are curated by examining coverage (and perhaps mutation kills) in the original code.
      - adrianN 9mo ago
        Right, that method is pretty good at finding unintentional behavior changes in a refactor. It is not very well suited for showing that the program is correct which is probably what your parent meant.
        pfdietz 9mo ago
        That doesn't seem like the same problem at all. The problem here was reimplementing the program in another language, not doing that while at the same time identifying bugs in it. Conversion of one program to another while preserving behavior is a problem much dumber programs (like compilers) solve all the time.
- augusteo 9mo ago
  n_u's point about LLMs as mentors for Rust's borrow checker matches my experience. The error messages are famously helpful, but sometimes you need someone to explain the why. I've noticed the same pattern learning other things. Having an on-demand tutor that can see your exact code changes the learning curve. You still have to do the work, but you get unstuck faster.
  - jauntywundrkind 9mo ago
    Storngly agreed. Or ask it to explain the implications of using different ownership models. I love to ask it for options, to what if scenarios out. It's been incredibly helpful for learning rust.
- carlmr 9mo ago
  >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.
  - eddd-ddde 9mo ago
    Clone doesn't work when you need to propagate data mutations, which is what you need most of the time. Another option is to just use cells and treat the execution model similarly to JavaScript where mutation is limited specific scopes.
spicyusername 9mo ago
I wonder when we'll start to see languages designed exclusively to be easy to write by agent programming.
- calvinmorrison 9mo ago
  or rather, maybe we stop seeing new features that are mostly there for developers and find some older languages are quite good and capable, maybe even easier since there's less to reason about
- krackers 9mo ago
  It seems the language would need to be strongly typed, have good error reporting and testing infrastructure, have a good standard library and high-level abstractions, and be "close enough" to existing languages. Go would seem to already fit that bill, any bespoke language you come up with is going to have less exposure in the training set than Go. Maybe Rust as a second, but Go's memory management might be easier for the LLM (and humans) than Rust's.
  - wenc 9mo ago
    Rust, Go and TypeScript are good bets. Python too -- hear me out. With spec-driven development to anchor things, coupled with property-based tests (PBT) using Hypothesis, it's great for prototyping problems. You wouldn't write mission critical stuff with it, but it has two advantages over so-called "better designed languages": massive ecosystem and massive training. If your problem involves manipulating dataframes (polars, pandas), plotting (seaborn), and machine learning, Python just can't be beat. You can try using an LLM to generate Rust code for this -- go ahead and try it -- and you'll see how bad it can be. Better ecosystems and better training can beat better languages in many problem domains.
    - Jtsummers 9mo ago
      > You wouldn't write mission critical stuff with it People do, they also write mission critical stuff in Lua, TCL, Perl, and plenty of other languages. What they generally won't do is write performance critical stuff in those languages. But there is definitely some critical communication infrastructure out there running with interpreted languages like these out there.
imperio59 9mo ago
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...
captain_coffee 9mo ago
> 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.
- PaulHoule 9mo ago
  I can believe LLM generated after being cut up into small slices that are carefully reviewed. But to have 20 copies of Claude Code running simultaneously and the code works so well you don't need testers == high on your own supply.
  - s1mplicissimus 9mo ago
    > high on your own supply. reminds me of a bar owner who died of liver failure. people said he himself was his best customer
  - justarandomname 9mo ago
    Sadly, I'm seeing a LOT of this kinda of usage. So much so, I know a couple people that brag about how many they have running at time same time, pretty much all the time.
    - strawhatguy 9mo ago
      Including Steve Yegge, is Gas Town orchestrator of LLMs is... wild. And complicated. https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04 https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...
      - PaulHoule 9mo ago
        I think he smokes more weed than I ever did.
srcreigh 9mo ago
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.
- ycombinatrix 9mo ago
  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.
  - drivebyhooting 9mo ago
    Come on that’s not true. How would you write and LRU cache in rust? It’s not possible in idiomatic rust. You either need to use unsafe or use integer indices as a poor man’s pointer.
    - ycombinatrix 9mo ago
      What's wrong with integer indices? They have bounds checking. You definitely do not need unsafe to do LRU.
    - mattgreenrocks 9mo ago
      Indices are fine. Fixating on the “right” shape of the solution is your hang-up here. Different languages want different things. Fighting them never ends well.
  - srcreigh 9mo ago
    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-wild-performance-tricks.html https://davidlattimore.github.io/posts/2025/09/02/rustforge-...
invalidname 9mo ago
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.
PeterWhittaker 9mo ago
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. Rust is worth the effort.
- nvader 9mo ago
  Thank you for this comment. I'm starting my rusty journey and I'm only a few months in. With the rise of autogenerated code, it's paradoxically much harder to go slow and understand the fundamentals. Your comment is reassuring to read.
  - s1mplicissimus 9mo ago
    Just wanted to add another bit of reassurance. At some point during my career people started "stack overflow coding". But ultimately someone has to fix the difficult issues and when you have the skills, you are coming out on top where others can just shrug and say "well there's no solution on stack overflow".
- justarandomname 9mo ago
  THIS, I can barely remember a time with lifetimes or the borrow checker caused me undue suffering but can recall countless times that abstractions (often in the async world) did and sometimes still do.
ajkjk 9mo ago
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.
- lacunary 9mo ago
  but the interesting thing about coordinate systems is that they do matter, a lot! many problems are much much easier to solve in one coordinate system than another.
  - ajkjk 9mo ago
    no doubt, but... also physics advanced in leaps and bounds every time someone figured out that ways of abstracting out a coordinate system.
    - ajkjk 9mo ago
      *figured out ways
- worthless-trash 9mo ago
  I would dearly love this to happen. There are some corner cases that won't fit the translation layer well, for example almost any beam languages philosophy of let it crash.. I imagine those languages will be left by the wayside.
fuddle 9mo ago
My take: "Any application that was written in Javascript, eventually will be written in a system language"
felipeccastro 9mo ago
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.
- jact 9mo ago
  Are Python apps really so easy to understand? I seriously disagree with this idea given how much magic goes behind nearly every line of Python. Especially if you veer off the happy path. I certainly am no fan of C but from a certain point of view it’s much easier to understand what’s going on in C.
  - awesome_dude 9mo ago
    One of the (many) reasons that I moved away from Python was the whole "we can do it in 3 lines" Oh cool someone has imported a library that does a shedload of really complicated magic that nobody in the shop understands - that's going to go well. We're (The Software Engineering community as a whole) are also seeing something similar to this with AI generated code, there's screeds of code going into a codebase that nobody understands is full across (give a reviewer a 5 line PR and they will find 14 things to change, give them a 500 line PR and LGTM is all you will see).
  - fwip 9mo ago
    Well-written Python apps are very easy to understand, especially if they use well-designed libraries. The 'magic' in Python means that skilled developers can write libraries that work at the appropriate level of abstraction, so they are a joy to use. Conversely, it also means that a junior dev, or an LLM pretending to be a junior dev, can write insane things that are nearly impossible to use correctly.
    - tasuki 9mo ago
      > Well-written Python apps are very easy to understand, especially if they use well-designed libraries. Oh. Why haven't I seen those?
nxobject 9mo ago
I hope this law applies to all of the Electron applications out there...
- ravedave5 9mo ago
  It might. An electron app is always a compromise, everyone knows several native apps would be better, but that's 3x the effort and maintenance. If you have LLMs porting to other systems they may be kinda janky, but is that worse than an electron app?
- furyofantares 9mo ago
  Oh don't worry, they'll recreate the bloat with millions of lines of bespoke slop per app.
leonidasv 9mo ago
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.
ElectronCharge 9mo ago
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.
- code_martial 9mo ago
  You can preallocate your data structures and control memory layout in Go. Also, despite GC there’s a sizeable amount of systems programming already done in Go and proven in production. Given how much importance is being deservedly given to memory safety, Go should be a top candidate as a memory safe language that is also easier to be productive with.
- Jtsummers 9mo ago
  The Go creators declared it a systems language and it's stuck around for some reason. Their definition was not the one most people would have used (leading to C, C++, Rust, Ada, etc. as you listed) but systems as in server systems, distributed services, etc. That is, it's a networked systems language not a low-level systems language.
- jandrewrogers 9mo ago
  I think the broad consensus (and I agree with it) is that a systems language cannot have a mandatory GC. The issue with GCs isn’t just latency-optimized applications like hard real-time. GCs also reduce performance in throughput-optimized applications that are latency insensitive, albeit for different reasons. Anything that calls itself a “systems language” should support performance engineering to the limits of the compiler and hardware. The issue with a GC is that it renders entire classes of optimization impossible even in theory.
noosphr 9mo ago
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.
- zephen 9mo ago
  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.
  - noosphr 9mo ago
    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?
    - zephen 9mo ago
      Obviously there's no holy water when it comes to go and concurrency bugs. 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.
- rankdiff 9mo ago
  why even write the code?? just tell AI to give output directly!
est 9mo ago
oh no, not this again. 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
cratermoon 9mo ago
I was expecting an insightful analysis of systems languages versus dynamically typed interpreted languages, but instead I got more sloperator hype.
felixfbecker 9mo ago
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.
- giancarlostoro 9mo ago
  Not sure, but I gave it a shot weeks ago and finally started building something using Rust for a project I've wanted to build for years now, in maybe 12 hours worth of effort total I've probably done several months worth of engineering effort (when you consider I only touch this project in my spare time). Every time I pick up Rust I fight it for hours because I don't do any Rust in my dayjob, but the LLM helps me pick up that Rust nuance slack wherever I fall short and I can focus on key architectural details as I have been obsessing over years now.
- chb 9mo ago
  A gross mischaracterization of the author's point (the word "type" doesn't even appear in the article). The author focuses on the cost of interpreted languages, which he describes as "memory hungry" and computationally expensive.
brown 9mo ago
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
- wmf 9mo ago
  No, because some language features like monkey patching have inherent runtime cost that cannot be eliminated. And if we reach superintelligence you can just let the AI invent its own language.
- jpc0 9mo ago
  Every time I see this take I ask myself if the person commenting does not understand that by definition a runtime has to do more work than a strictly compiled version of any said code and therefore can never be quicker. 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.
anon291 9mo ago
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.
yert3 9mo ago
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.
- jimbob45 9mo ago
  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.
  - esafak 9mo ago
    And Rust compilation is slow.
  - noosphr 9mo ago
    I don't know why you are being downvoted. Rust in the Linux kernel is basically all unsafe which is what I expected to happen the first time I heard about it.
  - ChadNauseam 9mo ago
    That’s not my experience. I use rust in my web application. It’s compiled to WASM and runs in the browser. About as high level as it gets. And I almost never feel I have to jump through hoops. The only time I do is when I’m implementing something that’s plain impossible in javascript, like zero-copy deserialization. On the other hand, I constantly have to jump through hoops in javascript. You literally cannot compare two objects for structural equality in JS without jumping through hoops. It’s unbelievable. Yet no one says javascript is not versatile enough to be used in high level contexts. It is fair to say that the way Rust deals with closures requires too much hoop-jumping to make a truly ergonomic reach equivalent
deleted 9mo ago
[deleted]
agentultra 9mo ago
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.
tehjoker 9mo ago
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.
adrianN 9mo ago
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.
sakesun 9mo ago
I think people stop arguing which is a better programming languages for a while, then, recently, they start to argue again on which is a better language for LLM.

105 points by almonerthis 9mo ago

deleted 9mo ago

[deleted]

n_u 9mo ago

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.

monero-xmr 9mo ago
I am old but C is similarly improved by LLM. Build system, boilerplate, syscalls, potential memory leaks. It will be OK when the Linux graybeards die because new people can come up to speed much more quickly
- lmm 9mo ago
  The thing is LLM-assisted C is still memory unsafe and almost certainly has undefined behaviour; the LLM might catch some low hanging fruit memory problems but you can never be confident that it's caught them all. So it doesn't really leave you any better off in the ways that matter.
  - monero-xmr 9mo ago
    I don’t code C much, is my passion side language. LLM improves my ability to be productive and quickly. Is not a silver bullet, but is an assist
  - tomrod 9mo ago
    Almost as well as a human doing it!
    - lmm 9mo ago
      Better than a human maybe. But still not good enough to rely on.
pfdietz 9mo ago
I don't see why it shouldn't be even more automated than that, with LLM ideas tested automatically by differential testing of components against the previous implementation. EDIT: typo fixed, thx
- n_u 9mo ago
  I'm assuming you meant to type > I don't see why it *shouldn't be even more automated In my particular case, I'm learning so having an LLM write the whole thing for me defeats the point. The LLM is a very patient (and sometimes unreliable) mentor.
- happytoexplain 9mo ago
  Defining tests that test for the right things requires an understanding of the problem space, just as writing the code yourself in the first place does. It's a catch-22. Using LLMs in that context would be pointless (unless you're writing short-lived one-off garbage on purpose). I.e. the parent is speaking in the context of learning, not in the context of producing something that appears to work.
  - pfdietz 9mo ago
    I'm not sure that's true. Bombarding code with huge numbers of randomly generated tests can be highly effective, especially if the tests are curated by examining coverage (and perhaps mutation kills) in the original code.
    - adrianN 9mo ago
      Right, that method is pretty good at finding unintentional behavior changes in a refactor. It is not very well suited for showing that the program is correct which is probably what your parent meant.
      - pfdietz 9mo ago
        That doesn't seem like the same problem at all. The problem here was reimplementing the program in another language, not doing that while at the same time identifying bugs in it. Conversion of one program to another while preserving behavior is a problem much dumber programs (like compilers) solve all the time.
augusteo 9mo ago
n_u's point about LLMs as mentors for Rust's borrow checker matches my experience. The error messages are famously helpful, but sometimes you need someone to explain the why. I've noticed the same pattern learning other things. Having an on-demand tutor that can see your exact code changes the learning curve. You still have to do the work, but you get unstuck faster.
- jauntywundrkind 9mo ago
  Storngly agreed. Or ask it to explain the implications of using different ownership models. I love to ask it for options, to what if scenarios out. It's been incredibly helpful for learning rust.
carlmr 9mo ago
>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.
- eddd-ddde 9mo ago
  Clone doesn't work when you need to propagate data mutations, which is what you need most of the time. Another option is to just use cells and treat the execution model similarly to JavaScript where mutation is limited specific scopes.

spicyusername 9mo ago

I wonder when we'll start to see languages designed exclusively to be easy to write by agent programming.

calvinmorrison 9mo ago
or rather, maybe we stop seeing new features that are mostly there for developers and find some older languages are quite good and capable, maybe even easier since there's less to reason about
krackers 9mo ago
It seems the language would need to be strongly typed, have good error reporting and testing infrastructure, have a good standard library and high-level abstractions, and be "close enough" to existing languages. Go would seem to already fit that bill, any bespoke language you come up with is going to have less exposure in the training set than Go. Maybe Rust as a second, but Go's memory management might be easier for the LLM (and humans) than Rust's.
- wenc 9mo ago
  Rust, Go and TypeScript are good bets. Python too -- hear me out. With spec-driven development to anchor things, coupled with property-based tests (PBT) using Hypothesis, it's great for prototyping problems. You wouldn't write mission critical stuff with it, but it has two advantages over so-called "better designed languages": massive ecosystem and massive training. If your problem involves manipulating dataframes (polars, pandas), plotting (seaborn), and machine learning, Python just can't be beat. You can try using an LLM to generate Rust code for this -- go ahead and try it -- and you'll see how bad it can be. Better ecosystems and better training can beat better languages in many problem domains.
  - Jtsummers 9mo ago
    > You wouldn't write mission critical stuff with it People do, they also write mission critical stuff in Lua, TCL, Perl, and plenty of other languages. What they generally won't do is write performance critical stuff in those languages. But there is definitely some critical communication infrastructure out there running with interpreted languages like these out there.

imperio59 9mo ago

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...

captain_coffee 9mo ago

> 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.

PaulHoule 9mo ago
I can believe LLM generated after being cut up into small slices that are carefully reviewed. But to have 20 copies of Claude Code running simultaneously and the code works so well you don't need testers == high on your own supply.
- s1mplicissimus 9mo ago
  > high on your own supply. reminds me of a bar owner who died of liver failure. people said he himself was his best customer
- justarandomname 9mo ago
  Sadly, I'm seeing a LOT of this kinda of usage. So much so, I know a couple people that brag about how many they have running at time same time, pretty much all the time.
  - strawhatguy 9mo ago
    Including Steve Yegge, is Gas Town orchestrator of LLMs is... wild. And complicated. https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04 https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...
    - PaulHoule 9mo ago
      I think he smokes more weed than I ever did.

srcreigh 9mo ago

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.

ycombinatrix 9mo ago
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.
- drivebyhooting 9mo ago
  Come on that’s not true. How would you write and LRU cache in rust? It’s not possible in idiomatic rust. You either need to use unsafe or use integer indices as a poor man’s pointer.
  - ycombinatrix 9mo ago
    What's wrong with integer indices? They have bounds checking. You definitely do not need unsafe to do LRU.
  - mattgreenrocks 9mo ago
    Indices are fine. Fixating on the “right” shape of the solution is your hang-up here. Different languages want different things. Fighting them never ends well.
- srcreigh 9mo ago
  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-wild-performance-tricks.html https://davidlattimore.github.io/posts/2025/09/02/rustforge-...

invalidname 9mo ago

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.

PeterWhittaker 9mo ago

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. Rust is worth the effort.

nvader 9mo ago
Thank you for this comment. I'm starting my rusty journey and I'm only a few months in. With the rise of autogenerated code, it's paradoxically much harder to go slow and understand the fundamentals. Your comment is reassuring to read.
- s1mplicissimus 9mo ago
  Just wanted to add another bit of reassurance. At some point during my career people started "stack overflow coding". But ultimately someone has to fix the difficult issues and when you have the skills, you are coming out on top where others can just shrug and say "well there's no solution on stack overflow".
justarandomname 9mo ago
THIS, I can barely remember a time with lifetimes or the borrow checker caused me undue suffering but can recall countless times that abstractions (often in the async world) did and sometimes still do.

ajkjk 9mo ago

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.

lacunary 9mo ago
but the interesting thing about coordinate systems is that they do matter, a lot! many problems are much much easier to solve in one coordinate system than another.
- ajkjk 9mo ago
  no doubt, but... also physics advanced in leaps and bounds every time someone figured out that ways of abstracting out a coordinate system.
  - ajkjk 9mo ago
    *figured out ways
worthless-trash 9mo ago
I would dearly love this to happen. There are some corner cases that won't fit the translation layer well, for example almost any beam languages philosophy of let it crash.. I imagine those languages will be left by the wayside.

fuddle 9mo ago

My take: "Any application that was written in Javascript, eventually will be written in a system language"

felipeccastro 9mo ago

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.

jact 9mo ago
Are Python apps really so easy to understand? I seriously disagree with this idea given how much magic goes behind nearly every line of Python. Especially if you veer off the happy path. I certainly am no fan of C but from a certain point of view it’s much easier to understand what’s going on in C.
- awesome_dude 9mo ago
  One of the (many) reasons that I moved away from Python was the whole "we can do it in 3 lines" Oh cool someone has imported a library that does a shedload of really complicated magic that nobody in the shop understands - that's going to go well. We're (The Software Engineering community as a whole) are also seeing something similar to this with AI generated code, there's screeds of code going into a codebase that nobody understands is full across (give a reviewer a 5 line PR and they will find 14 things to change, give them a 500 line PR and LGTM is all you will see).
- fwip 9mo ago
  Well-written Python apps are very easy to understand, especially if they use well-designed libraries. The 'magic' in Python means that skilled developers can write libraries that work at the appropriate level of abstraction, so they are a joy to use. Conversely, it also means that a junior dev, or an LLM pretending to be a junior dev, can write insane things that are nearly impossible to use correctly.
  - tasuki 9mo ago
    > Well-written Python apps are very easy to understand, especially if they use well-designed libraries. Oh. Why haven't I seen those?

nxobject 9mo ago

I hope this law applies to all of the Electron applications out there...

ravedave5 9mo ago
It might. An electron app is always a compromise, everyone knows several native apps would be better, but that's 3x the effort and maintenance. If you have LLMs porting to other systems they may be kinda janky, but is that worse than an electron app?
furyofantares 9mo ago
Oh don't worry, they'll recreate the bloat with millions of lines of bespoke slop per app.

leonidasv 9mo ago

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.

ElectronCharge 9mo ago

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.

code_martial 9mo ago
You can preallocate your data structures and control memory layout in Go. Also, despite GC there’s a sizeable amount of systems programming already done in Go and proven in production. Given how much importance is being deservedly given to memory safety, Go should be a top candidate as a memory safe language that is also easier to be productive with.
Jtsummers 9mo ago
The Go creators declared it a systems language and it's stuck around for some reason. Their definition was not the one most people would have used (leading to C, C++, Rust, Ada, etc. as you listed) but systems as in server systems, distributed services, etc. That is, it's a networked systems language not a low-level systems language.
jandrewrogers 9mo ago
I think the broad consensus (and I agree with it) is that a systems language cannot have a mandatory GC. The issue with GCs isn’t just latency-optimized applications like hard real-time. GCs also reduce performance in throughput-optimized applications that are latency insensitive, albeit for different reasons. Anything that calls itself a “systems language” should support performance engineering to the limits of the compiler and hardware. The issue with a GC is that it renders entire classes of optimization impossible even in theory.

noosphr 9mo ago

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.

zephen 9mo ago
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.
- noosphr 9mo ago
  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?
  - zephen 9mo ago
    Obviously there's no holy water when it comes to go and concurrency bugs. 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.
rankdiff 9mo ago
why even write the code?? just tell AI to give output directly!

est 9mo ago

oh no, not this again. 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

cratermoon 9mo ago

I was expecting an insightful analysis of systems languages versus dynamically typed interpreted languages, but instead I got more sloperator hype.

felixfbecker 9mo ago

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.

giancarlostoro 9mo ago
Not sure, but I gave it a shot weeks ago and finally started building something using Rust for a project I've wanted to build for years now, in maybe 12 hours worth of effort total I've probably done several months worth of engineering effort (when you consider I only touch this project in my spare time). Every time I pick up Rust I fight it for hours because I don't do any Rust in my dayjob, but the LLM helps me pick up that Rust nuance slack wherever I fall short and I can focus on key architectural details as I have been obsessing over years now.
chb 9mo ago
A gross mischaracterization of the author's point (the word "type" doesn't even appear in the article). The author focuses on the cost of interpreted languages, which he describes as "memory hungry" and computationally expensive.

brown 9mo ago

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

wmf 9mo ago
No, because some language features like monkey patching have inherent runtime cost that cannot be eliminated. And if we reach superintelligence you can just let the AI invent its own language.
jpc0 9mo ago
Every time I see this take I ask myself if the person commenting does not understand that by definition a runtime has to do more work than a strictly compiled version of any said code and therefore can never be quicker. 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.

anon291 9mo ago

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.

yert3 9mo ago

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.

jimbob45 9mo ago
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.
- esafak 9mo ago
  And Rust compilation is slow.
- noosphr 9mo ago
  I don't know why you are being downvoted. Rust in the Linux kernel is basically all unsafe which is what I expected to happen the first time I heard about it.
- ChadNauseam 9mo ago
  That’s not my experience. I use rust in my web application. It’s compiled to WASM and runs in the browser. About as high level as it gets. And I almost never feel I have to jump through hoops. The only time I do is when I’m implementing something that’s plain impossible in javascript, like zero-copy deserialization. On the other hand, I constantly have to jump through hoops in javascript. You literally cannot compare two objects for structural equality in JS without jumping through hoops. It’s unbelievable. Yet no one says javascript is not versatile enough to be used in high level contexts. It is fair to say that the way Rust deals with closures requires too much hoop-jumping to make a truly ergonomic reach equivalent

deleted 9mo ago

[deleted]

agentultra 9mo ago

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.

tehjoker 9mo ago

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.

adrianN 9mo ago

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.

sakesun 9mo ago

I think people stop arguing which is a better programming languages for a while, then, recently, they start to argue again on which is a better language for LLM.