Just stopped by to say Sutter is not only right to be reiterating Bjarne's position 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
C++ committee members (mainly Boehm, but also Stroutstrup) also deserve a lot of credit for giving us a well specified memory model for concurrency outside of functional languages. Rust basically copy/pasted the C++11 memory model wholesale. Rust's fearless concurrency owes a lot to standing on the shoulders of giants.
I’m not sure where you draw the conclusion that this was impactful. Intel had been sounding the alarm for at least a couple years at that point (longer if you were privy to private communication with them). Not to mention that C++ failed pretty miserably to enable safe concurrent and parallel programming for the masses, and the industry as a whole still struggles as a result.
That paper turned out to be enterily wrong, not only did single core performance keep increasing significantly, today most software is being written with almost no concurrency in mind
Languages have not yet evolved to multi-core properly IMO
I've sketched what I think an ideal "language of today" would look like, and one of the core tenets is making concurrent code explicit and part of the design surface.
You might imagine a webserver with main code like:
spawn(on_core: 0) {
await receive_packet(input)
}
Or iterating over "num_cpus" and doing the same thing, with hashing based on CPU number for shared-memory resources.
The problem is that when you build at this layer, you end up writing far more scheduling code than business logic. Eventually you've built the abstractions we already use today.
The vast, vast majority of software, and software developers, simply do not care about core affinity, NUMA, noisy neighbors, etc.
Even on systems or situations where this matters (massive number of cores and memory, multiple sockets, thousands of threads, etc.) the juice is rarely worth the squeeze.
Doubly so when you end up being I/O bound anyways.
Nearly every software developers wants their software to work across multiple deployment targets. Maybe you just target x86-64, and you don't care about the number of CPUs because you'll be upgrading your servers every couple of years.
No one wants to deal with difficult-to-reproduce issues related to scheduling in niche configurations. It's much more efficient for runtime or compiler engineers to solve these problems for us, leveraging the vast amount of resources of corporations to develop and test these features. Then you have a place your code can live happily ignorant of its runtime constraints.
And that, my friend, is the beauty of our industry.
Agreed. I've not liked the contract setup for various reasons. It seems like the proponents of it are mostly there because it scratches an itch in PL PhD studies rather than being an actually useful feature.
I remain unconvinced as why this is a necessary feature over the already existing `assert` statements.
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!
Does the existence of PEP 572 not similarly result in being paralyzed and overwhelmed at the number of ways to do something being greater than 1?
C++ definitely has complexity, but I'm surprised by the two examples specifically chosen. Which pointer? C++ only has 2: unique_ptr and shared_ptr (or 2.5 if you want to include weak_ptr but that necessarily means you already chose strong_ptr first). While this might be a complicated choice if you're just comparing to Python, but it shouldn't be if you're familiar with Rust since Rust has you make the same choice.
And then "how should I iterate" is similarly the same as any other language? Either a for or a for-each loop?
There's definitely baggage from 38 years of lessons learned, to be sure, just those examples are odd choices
Don't forget * (true pointer) and & (called a reference, more honestly a pointer that can't be repointed, except with UB it can _totally_ get repointed).
Features are deprecated and removed. It's uncommon but it happens when a new feature makes all use of the old feature unnecessary. Usually it's deprecated for a few versions and then removed some years later. You can always compile old code against an old standard.
C++ does have many ways to do anything. Most of that is historical, or due to features and library facilities with overlapping capabilities, or inherent to multi-paradigm programming languages.
Every C++ project is written in its own language. Its own "house flavor." This is true of all languages, but is particularly stark for a language as old, complicated, and powerful as C++.
I share the same sentiment and experience from trying to get into C++. I bought "A Tour of C++" (2022, Stroustrup), I read it back to back, and I thought to myself "it's not so bad, seems quite nice actually, specially the modules part"... oh boy. After 2 weeks writing a HTTP requests CLI tool I was feeling really demotivated, I gave up and went to rust, for no special reason, I just had it queued up after reading "The Rust Programming Language" book.
> pre-LLM, so maybe it's better now?
I came back to the toy tool some time later and used GLM 4.x to implement it further. I had a good experience with it and I understood the code it generated. From my experience, in general, LLM is a good mentor, if you are willing to ingest the content step by step. For me, it is no different from when I used StackOverflow (and other forums) to try and ask how a thing is done.
You're very diplomatic (yet downvoted), C++ is an abomination of a language. It just puts too much accidental cognitive load on developers. I understand that
- it shines for some tasks where Rust isn't capable enough
- it's impossible to get rid of because of all the code so we may as well modernize it
- there's an active community of people who built a career of being C++ experts and have no interest to see the language disappears.
Even in the LLM era, I find it's difficult to code in C++. The language has so many corner cases that LLMs make mistakes. My experience 6 months ago was that the code written by my agent had tons of complex linter warning (exceptions, lambda leaking references, futures whatever... that I just can't avoid because the codebase mixes all of this). Whenever possible, it's probably time to either modernize it or port it to Rust, component by component, until the C++ part is small or inexistant.
> As someone who spent a few weeks trying to get into C++ and kind of just gave up out of confusion
what should be conclude from this? this is like saying you tried to become a professional trapeze artist for a couple of days. C++ is complex and deep. what did you seriously hope to accomplish in a "few weeks"?
i started writing C++ professionally 4 years ago, i.e., i write it every single day at $JOB. there are still large parts of the language i'm not familiar with.
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.
I think "guaranteed contract enforcement" should be added to item D since that is explicitly called out as the only technical proposal that would change some NB votes from no to yes.
“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.
Linus stopped scaling sometime in the late 90s - 00s. That's when lieutenants took over more authority, and a more or less informal line of succession formed. BDFLs can promote their own replacements from trusted collaborators who share the vision.
> 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.
Well I mean you're just wrong, you can look at any of those languages (or https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere. But everyone pokes fun at the C++ committee and the wacky shit they cook up.
Design by committee just sucks. Coordinating and working with people is expensive, and a drag. If you have to, you have to, but for many projects you don't and shouldn't. An individual's design is always going to be more cohesive, and we can see it clearly looking at PL history IMO.
> Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere.
Guido stepped down from that role 8 years ago. It now has a 5-member steering council along with the core developers as the primary maintainers and decision makers.
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.
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.
I tend to wonder, in an alternate reality, where the buck stopped at C for systems languages, would we be better off because more people would use it and know how to fix memory related issues?
We’ve sent rockets into space running C/C++ and assembly. And that was long before C++11 rolled around.
I’m wondering because: man Rust is an ugly language. C is not perfect either, but it’s still pretty close to what it was FIFTY YEARS AGO.
Fast forward to now, and all we’ve come to is Rust? I just wonder why don’t we just keep using C, C#, and Java? I mean the former two are memory safe, and they can do “unsafe” just like Rust.
Another thing: why do we write pseudocode and not design languages to look like pseudocode? With Rust and modern C++ compile times you’d think the machine is parsing prose and turning it into assembly…
over-obsession with the language's aesthetics ignore that the type system / borrow checker / ... are good and legitimately assist with development and did so even before the widespread use of LLMs.
many of those who ended up as Rust developers came from C and C++, seeing improvement from what they were using.
languages have been designed more and more to allow for higher level behaviours, in Rust's case, although not pursuing psuedocode, generally allows for very high level abstractions. regardless the computer still has to run things, languages are typically deterministic in their handling and psuedocode leaves much undetermined, unfully specified.
[delayed]
Just stopped by to say Sutter is not only right to be reiterating Bjarne's position 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
C++ committee members (mainly Boehm, but also Stroutstrup) also deserve a lot of credit for giving us a well specified memory model for concurrency outside of functional languages. Rust basically copy/pasted the C++11 memory model wholesale. Rust's fearless concurrency owes a lot to standing on the shoulders of giants.
C++11 borrowed heavily from the Java memory model that came before it.
It's basically everyone learning from everyone else on what works and what doesn't work.
I’m not sure where you draw the conclusion that this was impactful. Intel had been sounding the alarm for at least a couple years at that point (longer if you were privy to private communication with them). Not to mention that C++ failed pretty miserably to enable safe concurrent and parallel programming for the masses, and the industry as a whole still struggles as a result.
That paper turned out to be enterily wrong, not only did single core performance keep increasing significantly, today most software is being written with almost no concurrency in mind
Languages have not yet evolved to multi-core properly IMO
I've sketched what I think an ideal "language of today" would look like, and one of the core tenets is making concurrent code explicit and part of the design surface.
You might imagine a webserver with main code like:
Or iterating over "num_cpus" and doing the same thing, with hashing based on CPU number for shared-memory resources.The problem is that when you build at this layer, you end up writing far more scheduling code than business logic. Eventually you've built the abstractions we already use today.
The vast, vast majority of software, and software developers, simply do not care about core affinity, NUMA, noisy neighbors, etc.
Even on systems or situations where this matters (massive number of cores and memory, multiple sockets, thousands of threads, etc.) the juice is rarely worth the squeeze.
Doubly so when you end up being I/O bound anyways.
Nearly every software developers wants their software to work across multiple deployment targets. Maybe you just target x86-64, and you don't care about the number of CPUs because you'll be upgrading your servers every couple of years.
No one wants to deal with difficult-to-reproduce issues related to scheduling in niche configurations. It's much more efficient for runtime or compiler engineers to solve these problems for us, leveraging the vast amount of resources of corporations to develop and test these features. Then you have a place your code can live happily ignorant of its runtime constraints.
And that, my friend, is the beauty of our industry.
Stroustrup's list of objections sounds quite sensible to me: https://www.stroustrup.com/Contracts_fundamental_flaws.pdf
Agreed. I've not liked the contract setup for various reasons. It seems like the proponents of it are mostly there because it scratches an itch in PL PhD studies rather than being an actually useful feature.
I remain unconvinced as why this is a necessary feature over the already existing `assert` statements.
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!
Does the existence of PEP 572 not similarly result in being paralyzed and overwhelmed at the number of ways to do something being greater than 1?
C++ definitely has complexity, but I'm surprised by the two examples specifically chosen. Which pointer? C++ only has 2: unique_ptr and shared_ptr (or 2.5 if you want to include weak_ptr but that necessarily means you already chose strong_ptr first). While this might be a complicated choice if you're just comparing to Python, but it shouldn't be if you're familiar with Rust since Rust has you make the same choice.
And then "how should I iterate" is similarly the same as any other language? Either a for or a for-each loop?
There's definitely baggage from 38 years of lessons learned, to be sure, just those examples are odd choices
Don't forget * (true pointer) and & (called a reference, more honestly a pointer that can't be repointed, except with UB it can _totally_ get repointed).
Made me LOL
Features are deprecated and removed. It's uncommon but it happens when a new feature makes all use of the old feature unnecessary. Usually it's deprecated for a few versions and then removed some years later. You can always compile old code against an old standard.
C++ does have many ways to do anything. Most of that is historical, or due to features and library facilities with overlapping capabilities, or inherent to multi-paradigm programming languages.
Every C++ project is written in its own language. Its own "house flavor." This is true of all languages, but is particularly stark for a language as old, complicated, and powerful as C++.
I share the same sentiment and experience from trying to get into C++. I bought "A Tour of C++" (2022, Stroustrup), I read it back to back, and I thought to myself "it's not so bad, seems quite nice actually, specially the modules part"... oh boy. After 2 weeks writing a HTTP requests CLI tool I was feeling really demotivated, I gave up and went to rust, for no special reason, I just had it queued up after reading "The Rust Programming Language" book.
> pre-LLM, so maybe it's better now?
I came back to the toy tool some time later and used GLM 4.x to implement it further. I had a good experience with it and I understood the code it generated. From my experience, in general, LLM is a good mentor, if you are willing to ingest the content step by step. For me, it is no different from when I used StackOverflow (and other forums) to try and ask how a thing is done.
You're very diplomatic (yet downvoted), C++ is an abomination of a language. It just puts too much accidental cognitive load on developers. I understand that
- it shines for some tasks where Rust isn't capable enough
- it's impossible to get rid of because of all the code so we may as well modernize it
- there's an active community of people who built a career of being C++ experts and have no interest to see the language disappears.
Even in the LLM era, I find it's difficult to code in C++. The language has so many corner cases that LLMs make mistakes. My experience 6 months ago was that the code written by my agent had tons of complex linter warning (exceptions, lambda leaking references, futures whatever... that I just can't avoid because the codebase mixes all of this). Whenever possible, it's probably time to either modernize it or port it to Rust, component by component, until the C++ part is small or inexistant.
> As someone who spent a few weeks trying to get into C++ and kind of just gave up out of confusion
what should be conclude from this? this is like saying you tried to become a professional trapeze artist for a couple of days. C++ is complex and deep. what did you seriously hope to accomplish in a "few weeks"?
i started writing C++ professionally 4 years ago, i.e., i write it every single day at $JOB. there are still large parts of the language i'm not familiar with.
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.
I think "guaranteed contract enforcement" should be added to item D since that is explicitly called out as the only technical proposal that would change some NB votes from no to yes.
I'm amazed. Someone somewhere conceived of a feature, and it wasn't put into C++!
“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.
No, ISO owns the standard, and they just shot down the committee's proposed draft.
The committee is part if ISO. Larger ISO shot down smaller ISO. Both are under the same system. WG21 is just the C++ subgroup of ISO.
> 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.
It's early days for WebGPU. Safari only enabled it in version 26, so for most of the web it's only a year old. Give it time.
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.
Linus stopped scaling sometime in the late 90s - 00s. That's when lieutenants took over more authority, and a more or less informal line of succession formed. BDFLs can promote their own replacements from trusted collaborators who share the vision.
> 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.
Well I mean you're just wrong, you can look at any of those languages (or https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere. But everyone pokes fun at the C++ committee and the wacky shit they cook up.
Design by committee just sucks. Coordinating and working with people is expensive, and a drag. If you have to, you have to, but for many projects you don't and shouldn't. An individual's design is always going to be more cohesive, and we can see it clearly looking at PL history IMO.
> Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere.
Guido stepped down from that role 8 years ago. It now has a 5-member steering council along with the core developers as the primary maintainers and decision makers.
> Or you do the BDFL model like Python, D, Zig, Odin, etc.
Python doesn't have a BDFL[1] and the others are toys.
1: Guido stepped down in 2018 and stopped involvement entirely in 2020 after an extended conflict with the community at large over PEP 572
> Python doesn't have a BDFL
Thanks, I relinquish that point and accept it as a success story for BDFL succession instead.
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.
The standard is the language. Again, you're arguing semantics.
The standard is a completely conceptual description of an idealized version of the language.
The implementations are the language.
One learns this when their standards-compliant code fails to compile.
[flagged]
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.
I tend to wonder, in an alternate reality, where the buck stopped at C for systems languages, would we be better off because more people would use it and know how to fix memory related issues?
We’ve sent rockets into space running C/C++ and assembly. And that was long before C++11 rolled around.
I’m wondering because: man Rust is an ugly language. C is not perfect either, but it’s still pretty close to what it was FIFTY YEARS AGO.
Fast forward to now, and all we’ve come to is Rust? I just wonder why don’t we just keep using C, C#, and Java? I mean the former two are memory safe, and they can do “unsafe” just like Rust.
Another thing: why do we write pseudocode and not design languages to look like pseudocode? With Rust and modern C++ compile times you’d think the machine is parsing prose and turning it into assembly…
over-obsession with the language's aesthetics ignore that the type system / borrow checker / ... are good and legitimately assist with development and did so even before the widespread use of LLMs.
many of those who ended up as Rust developers came from C and C++, seeing improvement from what they were using.
languages have been designed more and more to allow for higher level behaviours, in Rust's case, although not pursuing psuedocode, generally allows for very high level abstractions. regardless the computer still has to run things, languages are typically deterministic in their handling and psuedocode leaves much undetermined, unfully specified.