I would say Rust is a functional language that has been hammered into the shape of C++. It also draws heavily on ML.

I get why, and it makes it a better fit for its obvious “C++ reimagined, cleaner, and better” niche.

I miss the years of writing CLI tools, web servers and clients, in Ada (and of real-time complex distributed system...). Felt so simple and right and fast and robust. The code is still readable today and maintaining it is a zero effort today. Clean Java without the enterprise BS was a close second in ease of programming - boilerplate be damned.

I'm glad NVIDIA found a way to make GPUs programmable and got us out of the shaders tarpit, but did it have to be C++...

Until there is a machine that is natively functional, there is always going to an incentive to go lower level for more performance.

Even hardware (GPUs) that functional language could trivially exploit, it’s still higher performance to write low level code and manages all the memory imperatively

After going over that section again I can see it now.

Are these obvious signs of AI generation?

It's unfortunate, but to come across as genuine now I think you have to actively avoid AI-isms.

In this case it feels AI generated with human polish, or vice versa. A couple tells are "One caveat worth stating up front..." and of course, "...the shape of the language itself...".

So anything that has em dashes is now considered LLM generated?

Is that what they said? If that's not what they said, why are you putting words in their mouth in an attempt to weaken their statement into some completely ridiculous stupid strawman that is obviously not actually what they said?

"And honestly"

It kind of says so at the bottom:

Disclaimer: styling and error handling throughout this article were cleaned up with the help of AI.

The implication seems to be "light editing", but the LLM styling really comes through, so I guess that tracks.

The first thing that caught me off guard — and honestly, who would’ve expected this to be the memorable part — was IDE support, or the near-total lack of it.

I would have completely expected that.

I think when we're looking back on the 2020s we'll be struck by the Allocator obsession

All of the Handmade "C successor" languages seem to have this obsession, including not only Zig but Odin, C3 and Jai.

For some toy problems you can do clever allocator tricks and get a huge perf win. For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically so they're not paying to track allocations in the arena because they're all thrown away at the same time.

But a lot of real world software just isn't that simple. This doesn't make such features worthless, it just means they're one of a thousand tools the experienced developer could want in their toolkit, not really deserving headline status.

I think (for now), it is still relevant. A language is an abstraction, and a good abstraction, like a good LLM harness, can be quite valuable.

Let’s say I’m writing some concurrent code with an LLM. I’d probably feel much safer having it write Rust, rather than C. So even in a post-LLM world, languages will continue to evolve as long as abstractions can be improved.

Would recommend learning how to use arena allocation. You would have patterns like:

fn run_query(alloc) {

   arena = init_arena(alloc);

   defer arena.deinit();

}