Now that LLMs are writing 300% of the code, it makes sense to do it in the safest language, not the most human friendly one.

I suspect that Rust will start taking over as a dominant LLM output language.

I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate. Perhaps even safer than Rust.

The models are shockingly good at writing Rust. You don't even need to have familiarity with Rust to start using it now. You'll learn the language as you interact with the LLMs.

Rust is one of the safer languages, but saying that it is "the safest language" is just a baseless exaggeration.

Decades before Rust and long before the simplified language that was C, there were safe programming languages, where all invalid operations, numeric overflows or out-of-bounds accesses generated exceptions and where use-after-free was impossible, because either garbage collectors or reference counts were used.

Rust is much safer than C compiled with its bad default compilation options, but it did not bring much in comparison with other languages.

Even in C++, with appropriate rules, restrictions and discipline you can write programs that are guaranteed to be at least as safe as any Rust program, but unfortunately very few use C++ in this way, i.e. by strictly avoiding the features that are obsolete or unsafe.

> Even in C++, with appropriate rules, restrictions and discipline you can write programs that are guaranteed to be at least as safe as any Rust program

If by discipline, you mean running something akin to the borrow checker in your head, that's essentially tautologically true. The issue with that is that it's mentally draining and/or you will still make mistakes sometimes.

Now, I mean by using only custom types for things like arrays and pointers, which do access checks and automatic memory release, and not using unsafe features like built-in arrays, strings, pointers, or the incorrect integer type conversions inherited from C.

For maximum safety, beyond what Rust offers by default, in C++ it is easy to replace the built-in integer types with custom integer types, which check for overflows and allow only the correct type conversions. It is also easy to define distinct types for various kinds of physical quantities, for increased safety.

You do not need to run anything in your head. With appropriate type definitions, a C++ compiler will do anything that is required.

The problem is that because of the requirement for backwards compatibility, C++ is a huge junk collection. I think that more than half of C++ consists of obsolete features, which should never be used in new programs. There are various C++ style guides, but in my opinion even most of those are not very inspired.

Despite of its defects, C++ still has the advantage of extreme customizability. It is easy to write programs that appear to be written in a language that has no resemblance with C++ (inclusively by having different keywords and what appears to be a different syntax), but nonetheless they are valid C++ programs.

Such a customized C++ variant can mimic any safer language.

No. C++ doesn't have a garbage collector, and it doesn't have a borrowck, as a result any reference types are subject to ordinary human error because it can't garbage collect the target objects and it doesn't know when to destroy them otherwise.

The work to try to address this for C++ 29, half-finished and untried as it is - is extremely restrictive, you'd likely hate it, and that's just to solve this, the relatively easy problem.

Thing is, Rust wasn't content just to solve that easy problem. (Safe) Rust also doesn't have data races. The C++ standard doesn't say very much about data races, can't help you ensure they don't happen - it just explains that if they do that's Undefined Behaviour, game over.

I am not a huge Rust fan but the language did bring a few practical and useful innovations, while also keeping a focus on practice.

And no, C++ just doesn't make the same things easy or clean.

And no, "discipline and appropriate rules" were never enough.

The practical and useful innovations were invented else, Rust made them mainstream.

Yes.

The biggest innovation of Rust is bringing some of the good ideas from functional programming to low level programming. I'd also say that partially exposing data flow analysis to a proframmer is new.

Rust package management is quite good, and also not by any means an invention.

I am still not a fan of all the ugly macro programming systems and verbose syntax in the language.

Macros in Rust are really ergonomically terrible. Zig's approach here is way better.

The language I really want is somewhere inbetween those two languages.

The borrow checker in Rust is frankly novel. Cyclone had something somewhat similar, but not the same.

The broader ML-like type system in Rust is not novel, but the integration of the borrow checker -- and its move semantics more broadly -- with it... that form honestly is an innovation. And one I'd have a hard time living without at this point.

And also one I'd like to see in more languages! Especially a simpler one, closer to C.

Cyclone would be the closest to that I guess. RIP.

True! the borrow checker is a special thing. This is what i mean when i say "explicit data flow analysis".

In a way this is compiler internals exposed to a programmer.

> with appropriate rules, restrictions and discipline

This completely misses the point.

The rules can be enforced by a static code checker.

That is really not very different of rules enforced by the Rust compiler.

For someone who does a fresh start, using a Rust compiler may ensure safer programs out of the box, but that does not mean that the same results cannot be achieved by alternative means when using other languages, when the use of those languages makes sense for other reasons, and it is worthwhile to invest resources in making appropriate libraries and tooling.

In general, I recommend against the use of C++ in new projects, but I see much too often claims about things that are supposedly difficult or impossible to do in C++, which are just false.

I tried that, but the Rust build process was too painful, and agents seemed to burn a lot of tokens guessing how to get the code to compile. I rewrote my project in Elixir and it’s been going much more smoothly

Elixir is great, and I have recently started using it myself, but its not a substitute for Rust. Try writing device driver in Elixir, or anything CPU intensive.

GP said nothing of what they were building. Seems pretty probable it was a web service/application rather than a device driver.

That is my point. It might be better for some use cases, but those are very different from the ones Rust is best.

I’m building a heavily parallel dataflow system. I thought Rust might be good for concurrency.

You mean your LLMs had an easier time with Elixir. Do you actually know either of the two yourself?

what’s the difference

> I suspect that Rust will start taking over as a dominant LLM output language.

I doubt it. I think most people will become more entrenched in their favored ecosystem.

> I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate.

This is already happening. A couple months ago I came across this language that is engineered for AI and human consumption https://www.moonbitlang.com/

Rust will never be the dominant output by a country mile. It will be python and typescript.

> It will be python and typescript.

A waste.

This code will be high-defect and slow.

All of your LLM outputs should be Rust.

> rust? Ya it is the community

Why are Rust people so insufferable?

We get it. You like Rust. It's not a panacea.

You mean ADA? I'd agree, at least gcc can compile it so it's not limited to the very few architectures that rust supports.

> not limited to the very few architectures that rust supports

Of all the complaints about rust, this strikes me as one of weirdest. How much code do you actually write for architectures outside the Tier 3 support list?

0 because it's not supported.

However I did write ADA and C for those.

> However I did write ADA and C for those.

Ok, but recently? I too wrote code for obscure platforms once upon a time, but not in, say, the last 15 years.

Now that PCs, game consoles, and mobile devices are basically all either amd64 or ARM, there's just not such a long tail of weird platforms to develop for.

(the embedded world I will grant you, still lots of bespoke toolchains running around in that space)

Oh it wasn't in my current job but it was less than 15 years ago.

If people would just take the time to actually learn and appreciate the Analytical Engine they could bypass _all_ that noise...

I’m rather partial to Plankalkül actually