[anileated]

> Given LLM assistance, why wouldn't I write my web app layer in Rust or Zig?

Same reasons as with no LLM assistance. You would be choosing higher maintenance burden and slower development speed compared to your competitors, though. They will get it out faster, they will have fewer issues, and will be able to find people to support it more easily. Your product may run faster, but theirs will work and be out faster.

[zoogeny]

Lets imagine we are assembly programmers. You have a particular style of assembly that you believe gives you some advantage over your competitors. The way you structure your assembly gives you a lower maintenance burden and faster development speed compared to your competitors.

I show up and say "I have a C compiler". Does it matter at that point how good your assembly is? All of a sudden I can generate 10x the amount of assembly that you generate. And you are probably aghast, what crappy assembly my C compiler generates.

Now ask yourself: how often do you look at generated assembly?

Compilers don't care about writing maintainable assembly. They are a tool to generate assembly in high volumes. History has shown that people who use C compilers were able to get products to market faster compared to people who wrote using assembly.

So lets assume, for the sake of understanding my position, that LLMs will be like the compiler. I give it some high-level English description of the code I want it to run and it generates a high volume of [programming language] as its output. My argument is, the programming language that it outputs is important and it would be better for it to output into a language that low level native binaries. In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM.

[Vaguely2178]

> In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM.

A well tested compiler is far more deterministic than an LLM, and can be largely treated as a black box because it won't randomly hallucinate output.

[zoogeny]

Humans aren't deterministic. I've trusted junior engineers to ship code. I fail to see a significant difference here in the long term.

We have engineering practices that guard against humans making mistakes that break builds or production environments. It isn't like we are going to discard those practices. In fact, we'll double down on them. I would subject an LLM to the level of strict validation that any human engineer would fine suffocating.

The reason we trust compilers as a black box is because we have created systems that allow us to do so. There is no reason I can see currently that we will be unable to do so for LLM output.

I might be wrong, time will tell. We're going to find out because some will try. And if it turns out to be as effective as C was compared to assembly then I want to be on that side of history as early as possible.

[Vaguely2178]

> Humans aren't deterministic.

Exactly, which is why I would want humans and LLMs to write maintainable code, so that I can review and maintain it, which brings us back to the original question of which programming languages are the easiest to maintain...

[zoogeny]

Well, we're in a loop then because my response was "you don't care about maintainable assembly".

I want maintainable systems you want maintainable code. We can just accept that difference. I believe maintainable systems can be achieved without focusing on code that humans find maintainable. In the future, I believe we will build systems on top of code primarily written by LLMs and the rubric of what constitutes good code will change accordingly.

edit: I would also add that your position is exactly the position of assembly programmers when C came around. They lamented the assembly the C compiler generated. "I want assembly I can read, understand and maintain" they demanded. They didn't get it.

[Vaguely2178]

We're stuck in a loop because you're flip flopping between two positions.

You started off by comparing LLM output to compiler output, which I pointed out is a false equivalence because LLMs aren't as deterministic as compilers.

Then you switched to comparing LLMs to humans, which I'm fine with, but then LLMs must be expected to produce maintainable code just like humans.

Now you're going back to the original premise that LLM output is comparable to compiler output, thus completing the loop.

[anileated]

Again, your competitor will get there faster and with fewer bugs. LLMs are trained on human input and humans do not do great at low level languages. They churn out better Python than C and especially when it comes to refactoring it (have observed that personally).