I assumed that it meant that if you ran code at compile time or at runtime, the results should be exactly the same given the same inputs.

And those games do so in a language (C++) where allocators is not a headline feature, and is barely even supported at all in the standard library.

The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.

Exactly, hard to see why any of this matters anymore.

But do you still have enthusiasm for finding out about new language features or concepts? I'll do what it takes to get the job done, but the passion for it is totally gone.

It still boggles my mind that golang hasnt introduced rust-style enums

Yep, my point tho is more sentimental than technical. Let the LLM figure out the language details and just manage the output and deployment. It's ... not fun

"It's young, and it shows"

"Holds up"

"not a toy, but not a sprawling project either, and ideally.."

"And that’s the trap"

ctrl F "real" -> 6 usages

ctrl F "genuine" -> 4 usages

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.

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

Not OP, but I think the leading and trailing paragraphs were mostly human-written (and nice to read), but the memory leak example cases had a very different flavor of prose and code comments that smelled very Claude-y to me

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

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

You repeating this weird strawman take a million times doesn't make it true. Why don't you finally just put out some genuinely interesting projects demonstrating how everybody was doing it wrong, so people can make up their own mind and finally be convinced. There must be some true magic in those languages and platforms you mention, that should offset the pain of writing in upper case and with super long KEYWORDs everywhere, and to offset the cost of switching to a culture that has way less mindshare and way less of a software ecosystem around it.

FWIW I've actually worked for 6 months on a large old Delphi project. It was some performance work that, as almost always, mainly required getting the language crap out of the way. In the end I got the job done (100x-1000x speedup) but I wouldn't want to switch back to this ecosystem: Licensing costs, weird language warts there too. A slow moving ecosystem. Ultimately, I just need something that does what I tell it to do, reliably and fast, and that doesn't get in the way.

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