Arduino, Espressif, Google, Apple, Microsoft, IBM and ARM all... have the same C++ subset in use which is widely agreed to be all the good bits?
No? Maybe at least they've completely avoided political fights about the subset they're using, and all you'd find on that subject is an agreement that it's a matter of horses for courses, nobody is wrong?
Also no? Well I'm sure that the Standard Committee's key people will write a document everybody agrees is a foundation for how to use modern C++, they could call it the "Core Guidelines"...
Ah that didn't go well either did it. In fact as a C++ programmer you can probably even quote parts of the Core Guidelines you vehemently disagree with.
It's a mistake to imagine that if Linus said "We'll use C++" that would end this nonsense, it would just make it even worse as of course people want to allow/reject their favourite/most hated features.
They agree on a specific internal one, just like Linux could agree in one specific one, yes?
I am quite sure that when Rust happens to be lucky enough to have 40 years of history being deployed into production, we will also have our Rust Core Guidelines, yes?
It is a mistake to imagine any language besides C would end the nonense arguments used by Linus.
How do you figure? The C++ Core Guidelines date back to at least 2017, so 40 years before that would be 1977. At which point Stroustrup is still in Cambridge as a PhD student under Wheeler, he doesn't even travel to Bell Labs until after completing his Thesis.
Let's be honest here, the C++ Core Guidelines aren't because C++ is 20 or 30 or (if you squint very hard) 40 years old, they are a symptom of two things: 1. C++ programmers, including those on the Committee itself, don't agree about which dialect of C++ is good to use; 2: The ISO process is not well-suited to this work, even abused heavily it is a poor fit to the actual problem of standardizing a programming language under active development.
Rust avoids both these problems by choosing a more appropriate mechanism for decision making, one much more like that used at the IETF. The goal is to achieve consensus rather than getting one extra vote to put your favoured outcome over the line. The main casualties of a consensus approach are that "Marmite" proposals don't get far, however even if they survive the ballot process in a democracy they're likely to meet a terrible fate in the real world for the same reason - too many people hate them. On the other hand, mediocre proposals tend to get considerably improved during consensus making because there isn't any points scoring.
For example look at https://github.com/rust-lang/rust/pull/93208 -- The proposer initially wanted to offer Add<T> for Wrapping<T> but is it really clear this always does what the programmer expected? And if we're offering Add<T> for Wrapping<T> for symmetry we should also do Add<Wrapping<T>> for T right? So in the end the consensus is let's just offer AddAssign<T> because it's very clear in that case what's going on and it isn't symmetrical. And that's what will land in 1.60 next month.
Rust, the perfect language that still can't decide how to do asynchronous programming, has a endless collection of external crates for error propagation, yet has people that think they are the epitome of language design.
I will enjoy to see how perfection will be achieved in Rust ad eternum.
