std::map (which is not a hash map, which is what most people would expect), std::move (which doesn't move), std::vector (which is not a vector), and std::vector (which is not even a std::vector).

Tbh I never expected that experiment to go anywhere. I guess that leaves Carbon (and large scale efforts to rewrite C++ in Rust).

The common sentiment is that you didn't really want to do that. You expect higher returns from only having a single base model.

Then, dedicated APIs for wrapping behavior where you expect it to happen.

Imo it's better to approach Demon's Souls as an exploration puzzle game with RPG stuff and combat, not as an action RPG (such as Dark Souls 3).

I'd take Void Stranger or probably even Deadly Rooms of Death: The Second Sky over Stephen's Sausage Roll any day, I imagine.

In Rust these types of proposals are common, in C++ less so. The incredibly tedious release process encourages everyone to put in just as much complexity as they can safely get away with.

(Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)

(My personal theory is that early go had a somewhat misguided idea of simplicity, and preferred overloading existing concepts with special cases over introducing new keywords. Capitalization for visibility is another example of that.)

Instead of just having to track the arch repos, you suddenly have those and Manjaro's own stuff (and own package manager tool etc.), which is another point of failure. Every new bit of technology is another part that can fail.

That's how I learned a pretty important lesson about software engineering that still informs how I work to this day.

"A layer of abstraction on top of a stateful legacy system often doesn't result in a simpler system, it just introduces exciting new failure possibilities. This especially applies when the owners of the legacy system have no responsibility over the abstraction layer."