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

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

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

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

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.

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.

I think this is certainly true, except for the "each engineer [bringing] whatever syntax or language" point.

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.

I've also found myself thinking a lot about isomorphic languages, particularly the edge cases I run into when I start attempting to run through potential mappings for various aspects of syntax or language features in my mind.

> with all of the language-specific concepts stripped away

I've arrived at a somewhat different conclusion. I think we'll arrive at a maximally cumbersome, maximally verbose interchange format that isn't intended to be parsed by a human. One capable of expressing literally every feature of every language that it officially supports. Otherwise translation will necessarily be lossy and round trips with perfect fidelity impossible.

Even then certain paradigms that are common today simply don't seem possible to translate between arbitrary language pairs. I think the client language would also need to be tailored to support the paradigm. Consider how you would go about abstracting (for example) longjump in C and how fundamentally incompatible that is with (for example) Java in its present form. Or how you would deal with differences in ordering requirements as well as any implicit synchronization points between languages.

I figure that C++ will be a viable candidate for the interchange format if we wait another 10 years or so. Just need to add a borrow checker, first class continuations, full blown AST macros, and a runtime "eval" facility. It's slightly tongue in cheek but it's wild to think that actually it could almost work (including the bit about not being intended to be parsed by a human).

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.

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.

assembly is fun, python is fun, both get the job done.

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?

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.

I'd much more prefer to review something written in Rust or Go, even if I'd much rather write it in Python if I had to do it manually.

The better structure and clear typing makes the review much easier.

I've cooled significantly on Python now that there are a number of strongly typed languages out there that have also gotten rid of the boilerplate of languages Python used to compete with.

Readability gets destroyed when a function can accept 3 different types, all named the same thing, with magic strings acting as enums, and you just have to hope all the cases are well documented.

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.

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.

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.

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.

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.

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

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.

Lisp?

I'm always surprised when agents aren't working directly with the AST.

There has been at least one posted here in Hacker News, Mojo. Google shows some other similar attempts.

The real issue with doing this is that there is no body of code available to train your models on. As a result the first few look like opinionated Python.

Here's one attempt: https://x.com/sigilante/status/2013743578950873105

My take: Any gains from an "LLM-oriented language" will be swamped by the massive training set advantage held by existing mainstream languages. In order to compete, you would need to very rapidly build up a massive corpus of code examples in your new language, and the only way to do that is with... LLMs. Maybe it's feasible, but I suspect that it simply won't be worth the effort; existing languages are already good enough for LLMs to recursively self-improve.

Not going far enough - why would applications be written in either 'systems languages' or 'agent languages' if you have superintelligence too cheap to meter and you will amortize the costs over more than, say, a few days? Just write in raw assembler from a domain-specific design hyperoptimized for solely the task, the way Donald Knuth on steroids would.

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.

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.

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?

Oh don't worry, they'll recreate the bloat with millions of lines of bespoke slop per app.

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.

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.

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.

It seems like it may be true, but pointlessly true. I.e. yes, 90% of code is probably written by LLMs now - but that high number is because there is such a gigantic volume of garbage being generated.

If there's a human in then loop, actually reading the plans and generated code, then it's possible to have 90% of me code generated by an LLM and maintain reasonable quality.

Yeah, I would say it's pretty variable, and it depends on what you mean by the word write.

I've recently joined a startup whose stack is Ruby on Rails + PostgreSQL. Whilst I've used PostgreSQL, and am extremely familiar with relational databases (especially SQL Server), I've never been a Rubyist - never written a line of Ruby until very recently in fact - and certainly don't know Rails, although the MVC architecture and the way projects are structured feels very comfortable.

We have what I'll describe as a prototype that I am in the process of reworking into a production app by fixing bugs, and making some pretty substantial functional improvements.

I would say, out of the gate, 90%+ of the code I'm merging is initially written by an LLM for which I'm writing prompts... because I don't know Ruby or Rails (although I'm picking them up fast), and rather than scratch my head and spend a lot of time going down a Google and Stackoverflow black hole, it's just easier to tell the LLM what I want. But, of course, I tell it what I want like the software engineer I am, so I keep it on a short leash where everything is quite tightly specified, including what I'm looking for in terms of structure and architectural concerns.

Then the code is fettled by me to a greater or lesser extent. Then I push and PR, and let Copilot review the code. Any good suggestions it makes I usually allow it to either commit directly or raise a PR for. I will often ask it to write automated tests for me. Once it's PRed everything, I then both review and test its code and, if it's good, merge into my PR, before running through our pipeline and merging everything.

Is this quicker?

Hmm.

It might not be quicker than an experienced Rails developer would make progress, but it's certainly a lot quicker than I - a very inexperienced Rails developer - would make progress unaided, and that's quite an important value-add in itself.

But yeah, if you look at it from a certain perspective, an LLM writes 90% of my code, but the reality is rather more nuanced, and so it's probably more like 50 - 70% that remains that way after I've got my grubby mitts on it.

That depends on how you define "doomed". Most screwed up companies don't go belly up overnight. They get sold as fixer-uppers and passed between bigger firms and given different names until, finally, it is sold for parts. The way this works is that all parties behave as if the company is the opposite of doomed. It's in a sense correct. The situation hardly seems doomed if everyone has enough time to make their money and split before the company's final death twitches cannot be denied, in which case the company accomplished its mission. That of course doesn't mean everything from its codebase to its leadership didn't lack excellence the whole time.

In my experience, most of the NodeJS shops do this. Because, LLMs on the surface seemingly are good at giving you a quick solution for JS code. Whether it's a real solution or patchwork is up for debate, but, for most mid-level to junior devs, it's good enough to get the job done. Now, multiply this workflow 10x for 10 employees. That's how you end up with a complete rewrite and hiring a senior consultant.

Its insane to me seeing this kind of thing. I write 100% of my code by hand. Of developers I know, they write >95% of code by hand

>We are entering an era where the Brain of the application (the orchestration of models, the decision-making) might remain in Python due to its rich AI ecosystem, but the Muscle, the API servers, the data ingestion pipelines, the sidecars, will inevitably move to Go and Rust. The friction of adopting these languages has collapsed, while the cost of not adopting them (in AWS bills and carbon footprint) is rising.

This is the most silicon valley brain thing I've seen for a while

We're entering an era where I continue to write applications in C++ like I've always done because its the right choice for the job, except I might evaluate AI as an autocomplete assistant at some point. Code quality and my understanding of that code remains high, which lets me deliver at a much faster pace than someone spamming llm agent orchestration, and debuggability remains excellent

90% of code written by devs is not written by AI. If this is true for you, try a job where you produce something of value instead of some random silicon valley startup

they just have to keep repeating it

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.

why even write the code?? just tell AI to give output directly!