The point is not a comparison with Rust per-se, but the fact that a better implementation of the idea was mathematically and/or technically possible; and the personal opinion that such huge footguns that the language accumulates over the years are maybe signals of having needed more thought to them before they were considered ready.

e.g. if something as simple of a inconspicuous std::move in the wrong place can break the whole assumption about move semantics, then make that impossible to do, or at least do not make it the default happy path, before you consider it production ready. What the heck, at the very least ensure it will become a compiler warning?

Hence the mention to Go and how they follow exactly this path of extending discussion as long as needed, even if it takes 10 years, until a reasonable solution is found with maybe small gaps, but never huge ones such as those explained in this article (plus tens of others in any other text about the language)

▲

pjmlp 9 hours ago | parent [-]

It took 13 years to get C++11, actually.

Go's discussion is interesting, given how much programming language design history, and flaws of existing languages, they ignore to this day.

▲

j1elo 8 hours ago | parent [-]

A bit more if we consider the "bugfixing" release that was C++14 :)

But yeah it makes sense, given how that was the jumpstart of the whole modernization of the language. I believe it was a big undertake that required the time it took. Still years have passed and footguns keep accumulating... it wouldn't hurt to have a mechanism to optionally drop the old cruft from the language. Otherwise everything stacks on top in the name of backwards compatibility, but at this pace, how will C++36 look like?

▲

mackeye 7 hours ago | parent | next [-]

a member of the c++ committee (herb sutter) is writing an compiler for an alternative c++ syntax [0], to c++, with the intent to restrict some semantics of the language for less UB, surprises, etc. i think less implementation-defined behavior is incredibly important; rvo vs std::move, dynamic function call optimization, i wish i didn't have to search asm to check for...

[0]: https://github.com/hsutter/cppfront

▲

pjmlp 7 hours ago | parent | prev [-]

While I share the sentiment, compare C#14 with C# 1.0, Java 25 with Java 1.0, Python 3.14 with Python 1.0.

While C++ might be worse, when you have 300+ doing proposals every three years, others aren't safer from similar churn, even if on smaller volume, and trying to keep backwards compatibility going.

And we all know what happened in Python.

Also Rust editions contrary to what many think, only cover a specific set of language evolution scenarios, it isn't anything goes, nor there is support for binary libraries.

As for a better C++, contrary to C, where it is business as usual, there are actually people trying to sort things out on WG21, even if isn't as well as we would like to.

"Making C++ Safe, Healthy, and Efficient - CppCon 2025"

https://youtu.be/p52mNWsh-qs?si=AEs1dtr6_iknzATv

▲

gpm 6 hours ago | parent [-]

> nor there is support for binary libraries.

This is a weird call-out because it's both completely incorrect and completely irrelevant to the larger point.

Rust absolutely supports binary libraries. The only way to use a rust library with the current rust compiler is to first compile it to a binary format and then link to it.

More so than C++ where header files (and thus generics via templates) are textual.

Cargo, the most common build system for rust, insists on compiling every library itself (with narrow exceptions - that include for instance the precompiled standard library that is used by just about everyone). That's just a design choice of cargo, not the language.

▲

pjmlp 6 hours ago | parent [-]

Rust does, Rust editions do not have a story for them.

	▲	gpm 6 hours ago \| parent [-]
		The story is that it must not matter which edition a library was compiled with - it's the boundary layer at which different editions interoperate with eachother.