Comment by pjmlp
14 hours ago
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"
> 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.
Rust does, Rust editions do not have a story for them.
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.