I get what you mean, but there is a key difference and I think that difference is driving a good portion of then for/against comments in this thread and elsewhere. The entirety of the Rust Principles, etc, seems to stem from the belief, supported by Niko in the Principles blog post and others by wording, that Rust is not just a programming language, but is a ‘community’. I can find no analogue in the C++ Committee, or user base generally. C++ is a programming language that individuals and groups use to make software, full stop. This difference leads to arguments/stances/positions that have very little to do with the material definition of the technological tool and more to do with some loosely defined feelings of ‘community’. The C++ Committee story was primarily about Google and other large corporate interests advocating a large techno local change in the language to benefit their use case with no input or consideration for other users of the tool, but this seems to be primarily focused on feelings of non-community control and business structuring. Maybe I’m wrong and Amazon is having an influence on Rust, the programming language, that disregards fit for purpose for non-Amazon developers, but I’d need to see something to support that before your comparison is a better fit.
The C++ Committee story was primarily about Google and other large corporate interests advocating a large techno local change in the language to benefit their use case with no input or consideration for other users of the tool
As I posted in the sibling comment, the Goals submission is at [1]. The Reddit and HN threads are pretty easy to search for (and there were quite a few). Summary, as I remember it, a group of primarily FAANG, with a large Google presence, authored a submission for the C++ Committee which was effectively a flag in the sand saying they (and their very deep pockets) wanted C++ to be primarily gear toward large, modern style development at large company scale. Removal of backwards comparability, limiting standard to only 64 bit architecture, preference for unstable ABI and language standard, etc. The document acknowledges that the use case they want the committee to push C++ towards is not for everyone, primarily because they all represent large money/scale interests, but they want the committee to go there way anyway.
You are correct. I may have read more into GP’s post than they intended. I assumed given the issues present in the tread and the original tweets, I assumed they were referring to the Committee submission document from 2020 [1] and the ‘uproar’ from non-FAANG developers.
Well, given that Google has reduced their contributions to ISO C++ and clang/LLVM, it appears the ISO is working as intended, where everyone has one vote, despite wanting more.
Ultimately the votes at ISO are on behalf of sovereign entities, and so you should be glad that it rarely comes to that, since I don't think you necessarily agree that Ireland and Kenya each ought to have the same weight as the United States of America when it comes to C++.
I would suggest the "reduced contributions" means that - unsurprisingly - Google thinks Chandler, Titus and co. were right and so since the C++ Committee doesn't endorse the performance goals that means C++ will gradually become less suitable for them and they should expect to begin migrating off it in the foreseeable future.
In Prague in 2020 the committee also signalled that it recognised the concerns about Undefined Behaviour from much of the C++ programmer community, but as with Epochs, the enthusiasm for actually doing anything is extremely limited, the committee promises that it doesn't want to actively make things worse if possible, which is as Antonin Scalia would say "Weak sauce".
So, I think the direction of C++ for the next decade is, maintain old C++ code, ensure opportunities for people writing books and selling consultancy, don't worry too much about making it any faster, nor any safer. Plenty of people will be happy with that. Lots more will not.
One of the things to watch from Google will be whether it deprioritizes LLVM or mostly Clang. Lots of other interesting projects care about LLVM and traditionally benefited from work done to make Clang better, but if Clang ceases to be the priority the LLVM work still needs to be done.
