Just stopped by to say Sutter is not only right here, he is also the author of IMO the most impactful paper regarding the progress of hardware performance and the shift to concurrent execution: https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf
This is a well-written and quite diplomatic summary by Herb Sutter. I'm not plugged in enough to be sure he's correct that Stroustrup's opposition was the main reason the C++26 vote failed where others have passed, but it sounds plausible.
It also lists 6 possible paths forward for C++26 with pros and cons. I think they are roughly:
A. Skip an official C++26 standard but roll these features into C++29.
B. Remove contracts from C++26 and pass it.
C. Say "please" and vote again.
D. Tweak contracts regarding virtual functions and vote again.
E. Pass C++26 as many different countries' national standards rather than an international standard.
F. Do E and also consider leaving ISO and moving to ANSI/INCITS instead.
As someone who spent a few weeks trying to get into C++ (pre-LLM, so maybe it's better now?) and kind of just gave up out of confusion, I really found it challenging to deal with the multiple different ways to do something. I mean, which pointer should I use? How should I iterate? I'm sure there's an answer to this, but I just found it easier to go back to python and hit up rust when I needed it.
It seems like part of the concern is that the feature needs to be shipped right the first time because it'll live forever. Perhaps allowing features to be deprecated and then removed could help?
But idk, I haven't written anything that lasted 36 years, so maybe the current approach is for the best!
“Owners”? No one owns a language. People will do what they find pragmatic, practical and necessary. A committee who thinks they own a programming language has become pretentious and misunderstands their relationship with developers.
You're arguing semantics. The committee owns the C++ standard and its future. It's not pretentious - not having such a governing body leads to either divergence or stagnation, both of which are usually fatal.
> not having such a governing body leads to either divergence or stagnation
Or you do the BDFL model like Python, D, Zig, Odin, etc.
I think it works better. A language that reflects the vision of an individual deeply thinking about the interactions of language features, and being able to say "no" to anyone/everyone has many benefits.
Committees make me think of the Web, C++, Swift, etc., and they have a lot of "odd" decisions that have had a heavy cost. Swift has https://www.swift.org/swift-evolution/, but a lot of ideas with minority support were pushed through by Apple (for SwiftUI mainly), against overwhelming community feedback.
And the Web has had a lot of "duds" when you think of WebGPU, WASM (not saying it's bad, but people clearly want to stop writing TS/JS and they haven't made that a reality yet, at least in a way I'd call "successful"), etc.. Oh and DRM in the browser sucks. I forget the details but I was goofing around with FreeBSD Desktop and couldn't get various things to work due to some browser DRM bullshit. https://en.wikipedia.org/wiki/Widevine if curious.
BDFL neither scales nor perseveres. People have multiple things competing for their time and attention. They get old. They probably want to retire eventually. Eventually they die. If you want something to last more than a decade or two, BDFL is a poor choice.
It’s pretentious to say they own the language. They own their standard. Yet every major compiler implements something else and are all called c++ compilers.
Maybe we should all just use Rust in the holy and consecrated name of memory safery. Oh, whoops, Rust is not memory safe, and usage of unsafe is widespread in some algorithmic work, the kind of already-difficult work where the extra difficulty of unsafe worsens matters.
What does that have to do with C++? Enormous pressure was put on C++ to change, in the name of holy memory safety, and C++ contracts was claimed by some to directly address memory safety. And the pressure came in large part from the Rust Foundation and related parties and individuals, such as Steve Klabnik. Funnily enough, Steve Klabnik is very active on C++ forums, and he has "strong forum-voting powers" both here and elsewhere.
That push for holy memory safety was not done in the interest of improving C++ or improving the state of programming. If they, Rust Foundation and company, had had an interest in improving C++, they would instead have tried to add the actually good parts of Rust to C++, namely tagged unions and pattern matching.
Their focus is also in many ways not beneficial to neither Rust nor programming generally, since a lot of energy is spent hiding the actual issues of Rust, thus diverting resources and attention away that could have been spent improving and fixing Rust.
Perhaps Mozilla was right in paying mental-medication-taking Steve Klabnik the least for his community-focused work, after all, his primary focus was not engineering, and he might harbour a burning hatred and envy for actually talented engineers. Or maybe Mozilla should have fired him while they had the chance long ago.
imagine you run into ub in your C program. Suddenly every single loc of your project, including dependencies, are in scope.
With Rust, only the unsafe blocks are in scope. The point of Rust is not to eliminate unsafe code, but to make it not scale with the size of your program. There is no good reason for those to be coupled.
It also lists 6 possible paths forward for C++26 with pros and cons. I think they are roughly:
A. Skip an official C++26 standard but roll these features into C++29.
B. Remove contracts from C++26 and pass it.
C. Say "please" and vote again.
D. Tweak contracts regarding virtual functions and vote again.
E. Pass C++26 as many different countries' national standards rather than an international standard.
F. Do E and also consider leaving ISO and moving to ANSI/INCITS instead.
It seems like part of the concern is that the feature needs to be shipped right the first time because it'll live forever. Perhaps allowing features to be deprecated and then removed could help?
But idk, I haven't written anything that lasted 36 years, so maybe the current approach is for the best!
Or you do the BDFL model like Python, D, Zig, Odin, etc.
I think it works better. A language that reflects the vision of an individual deeply thinking about the interactions of language features, and being able to say "no" to anyone/everyone has many benefits.
Committees make me think of the Web, C++, Swift, etc., and they have a lot of "odd" decisions that have had a heavy cost. Swift has https://www.swift.org/swift-evolution/, but a lot of ideas with minority support were pushed through by Apple (for SwiftUI mainly), against overwhelming community feedback.
And the Web has had a lot of "duds" when you think of WebGPU, WASM (not saying it's bad, but people clearly want to stop writing TS/JS and they haven't made that a reality yet, at least in a way I'd call "successful"), etc.. Oh and DRM in the browser sucks. I forget the details but I was goofing around with FreeBSD Desktop and couldn't get various things to work due to some browser DRM bullshit. https://en.wikipedia.org/wiki/Widevine if curious.
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
https://github.com/rust-lang/rust/blob/main/library/core/src...
What does that have to do with C++? Enormous pressure was put on C++ to change, in the name of holy memory safety, and C++ contracts was claimed by some to directly address memory safety. And the pressure came in large part from the Rust Foundation and related parties and individuals, such as Steve Klabnik. Funnily enough, Steve Klabnik is very active on C++ forums, and he has "strong forum-voting powers" both here and elsewhere.
That push for holy memory safety was not done in the interest of improving C++ or improving the state of programming. If they, Rust Foundation and company, had had an interest in improving C++, they would instead have tried to add the actually good parts of Rust to C++, namely tagged unions and pattern matching.
Their focus is also in many ways not beneficial to neither Rust nor programming generally, since a lot of energy is spent hiding the actual issues of Rust, thus diverting resources and attention away that could have been spent improving and fixing Rust.
Perhaps Mozilla was right in paying mental-medication-taking Steve Klabnik the least for his community-focused work, after all, his primary focus was not engineering, and he might harbour a burning hatred and envy for actually talented engineers. Or maybe Mozilla should have fired him while they had the chance long ago.
With Rust, only the unsafe blocks are in scope. The point of Rust is not to eliminate unsafe code, but to make it not scale with the size of your program. There is no good reason for those to be coupled.