6 ms·

Bjarne Stroustrup's Plan for Bringing Safety to C++

67 points by wyldfire 3y ago

KingLancelot 3y ago
[dead]
sseagull 3y ago
I like the practicality of this. I know everyone (particularly here) is excited about new languages, and some of them are great. I'm learning some myself. But there's billions (?) of lines of existing C++. For those projects, there are two options: (1) improve compiler static analysis, possibly incrementally update it with something like 'profiles'. (2) Do nothing. There is no "rewrite it in another language" option. Those are your choices, and even (1) is a stretch. So I do think we should be moving forward on both fronts - improve C++ so that existing code can be made safer, as well as push the envelope with newer safer languages.
- r0ze-at-hn 3y ago
  Option 3) Most businesses have a lifetime, most software has a lifetime, and one day they are run for the very last time. The same will happen for code written in C++, most of it will simply die. Some might live on in a GitHub repository, never to be compiled again. Option 4) The business core is turned into a library. Everything from the command line tools to UI all wrap this in other languages. Everything that is not the core is deleted. With the C++ committee after the last two decades I am firmly in the I'll believe [shiny feature] when I see it camp.
  - pjmlp 3y ago
    COBOL 2023 was just ratified, so C++ still quite a road ahead of itself even if we rewrite everything starting today.
- tobias12345 3y ago
  > There is no "rewrite it in another language" option. How about "Wrap your C++ code in FFI wrappers and use it from a safer language"? It is conceptually not much different to "rewrite all your C++ code to be profile compliant" -- which will involve wrapping existing "unsafe" C++ code you can not just port over to mark it up in such a way that tooling can reason about it better.
lelanthran 3y ago
He's right in many ways. They did the best they could at the time under the constraints that they had - try adding type-safety to K&R C while maintaining backwards compatibility with K&R C. But now the only way forward I see for C++ to maintain its position as a mainstream language is to draw a hard line in the sand and effectively only keep all of the stuff that people refer to when they say "write in Modern C++", and remove everything else.
- AlotOfReading 3y ago
  That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For another, the error messages that can be emitted are terrible. Worse, it relies on the compiler to do a lot of heavy lifting that just isn't going to happen in the industries it's needed most for years. It's also opt-in rather than opt-out. Depending on the as-yet(?) unclarified constraints on UB, there may be yet more footguns for those unwise enough to attempt incremental rewrites. Also, because it's C++ there are already a bunch of visual warts like having to continue using gsl::span instead of std::span because of subtly different semantics. Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings.
  - lelanthran 3y ago
    > That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. Subtly different - by "a line in the sand" I meant that anything past this line is New C++ and anything behind the line is Old C++. Your compiler for New C++ wouldn't compile anything that is Old C++, and the Old C++ compiler wouldn't compiler much of New C++. Two different languages that both have Current C++ as an ancestor. > I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For making it a set of errors in the Current C++, yes, it's a bad proposal and not what I proposed. Under my proposal, it's not like your Old C++ compiler will suddenly stop existing, or stop being supported, would it? You'll effectively have decades before this is the case. > Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings. Yeah. You list either New C++ or Old C++ (or both, if you can). Like many others, I gave up on C++ a long time ago and stick with C for those projects that I both 1) do solo, AND, 2) need the low-level access and performance.
hyperman1 3y ago
As ssoneone who used to like C++ but has moved on to rust: There are good things in here, but I am not convinced they go far enough, even if completely implemented. The good: I see a new Stroustrup. At the time of the NSA report, he seemed to be in denial about the position C++ was in, security wise. The 'just be carefull'- wont-scale slide seems a much better basis to start the discussion from.He seems to propose something similar to rust editions, allowing problematic parts of the language to be switched off, with an escape hatch similar to unsafe. If this would work out, rewrite it in rust could no longer be needed. There is an upgrade path for C++, and an incentive to use it. The bad: There seems to be still some denial in there. I see rust providing today what he calls a fantasy. In fact, it existed before C with languages like ADA, except the ecosystem just wasnt there. Second problem is the timeline. 3 years for a new language version, then 10 years for the ecosystem to upgrade, then another 10 years until everyone is convinced this new way of working should be better? It seems both an aggressive timeline and a promise it wont happen in my professional lifetime. Also, a path forward is not a commitment, e.g. to completely eradicate undefined behavior outside unsafe blocks. All and all, and I hope I am wrong here, I read this as too little, too late. Rewriting it all from scratch is hard, but erasing the culture of the C++ ecosystem seems a lot harder.
- nyanpasu64 3y ago
  Rust solves some problems of C++ (memory safety for common-cases of code) while introducing new problems (less expressive safe code and harder-to-write unsafe code, expanded UB when trying to expose &mut to safe code from raw pointers, or RefCell runtime panics).
  - saghm 3y ago
    I don't disagree about unsafe Rust being trickier than people might realize, but "RefCell runtime panics" bring a "new" problem is a bit of a stretch; it's strictly better than UB, which can also crash. Making a situation that used to be "maybe crash, maybe accidentally continue running and make things far wise than crashing" instead "definitely crash" is a reduction of an existing problem rather than a new one.
zamalek 3y ago
I really hope that this yields fruit. I'll never touch the language again myself, but we need to get the hardcore C++ fans on board. However, > By the time it happens — 40 years from now — we’ll probably have 20 different ones, and they have to interoperate. C++ doesn't interoperate with anything either due to name mangling being unspecified.
- GoblinSlayer 3y ago
  C/C++ can't even interoperate with itself due to varying text encodings, integer sizes, different file system capabilities, fork and stuff like that.
jokoon 3y ago
I love c++, but honestly I see less reasons to use it instead of slower things like python ruby etc. C++ is just too slow to compile and it's really not nice to use. C++ is great to write libraries that need to be fast, but in general, most of what people write should be in interpreted languages, and when speed really matters, use C++ to remove bottlenecks. Most of software doesn't need to be written in C++.
- GoblinSlayer 3y ago
  False dichotomy fallacy, C++ and python are not the only languages.
- burjui 3y ago
  As if C++ was the only statically typed language compiled to native code.
tobias12345 3y ago
I am disappointed: I have to wait a few years for the C++ committee to define profiles. Then a few more years for tooling to become available. Then a few more months for the tooling to become interoperable enough to actually be used in existing build tooling. Then a few more years for all my major dependencies to actually use profiles. Then I can rewrite my code in profiles-C++ -- or by writing safety wrappers around my existing code and all dependencies that do not support the right profiles. Or I can switch to a memory safe language today. I still have to write safety wrappers around all my code to interface with that, but I'll have a couple of years of a head-start to anybody sticking to C++.
- pjmlp 3y ago
  Not everyone has that option, thus we need to also improve C and C++. As an example, while Microsoft slowly adopts Rust, it keeps putting out best practices and improved tooling, they aren't going to rewrite the whole Windows, XBox and Azure C++ code into Rust for the next couple of decades, or how long they would still matter on the market place. Or Apple with they increased adoption of Swift, while still having to deliver C, C++, Objective-C and Objective-C++ stuff. Or Google slowly adopting Rust, yet it still isn't officially supported on the NDK, or being the main language used on V8.
  - tobias12345 3y ago
    Which option? To write wrappers now instead of later? I just see no way to be able to use current C++ code in a profiles world without wrappers or even a rewrite. For some code with decent semantics, a modern enough code base and clean APIs that wrapper might be just slapping a "compatible with profile FooBar" somewhere. On the other hand those are the APIs that are the easiest to wrap for other languages, too. > As an example, while Microsoft slowly adopts Rust, it keeps putting out best practices and improved tooling, they aren't going to rewrite the whole Windows, XBox and Azure C++ code into Rust for the next couple of decades, or how long they would still matter on the market place. So they are making the jump away from C++ now, wrapping their existing code to reuse it from safer languages. Smart :-)
cvalka 3y ago
The guy needs to burn in hell.
- dang 3y ago
  Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
gemstones 3y ago
I think it's realistic to expect this to be the work of decades! Great talk by Bjarne. Will attrition make a decades-long timeline viable? I'd never touch C++ myself, I'm too scared there will be a long period of time where I'd be actively dangerous and introduce security holes. I am learning Rust, because that type of low-level systems programming seems like a valuable thing to have. Are there young devs who aspire to go through the C++ learning curve? I'd love to hear about your experience!
pomatic 3y ago
Am I an idiot? Re-working language definitions and compilers is _hard_. Instead, why not accept there are flaws and try to catch/fix them? I can see two obvious paths (I'm sure there are more) to address (N.P.I) these issues - top down: AI based code review. Wouldn't that catch 80%+ of common errors? Bottom up: Aggressive hardware fencing of memory access, much finer grained than pages? What am I missing?
- burjui 3y ago
  If you need a superhuman intellect (admittedly, a narrow one) in order to write sane code in a language, that means that language is no longer a good language for humans. The current trend of slapping an AI onto everything makes me nervous about our future: why put effort into careful design when it's easier to feed terabytes of data to an AI and hope something good comes out? Nevermind that you now have to sift through tons of garbage it produces. C++ is deeply flawed to say the least, you won't fix it with AI or anything. It's time to ditch it already.
afdbcreid 3y ago
I'm skeptical of profiles-C++. I'm afraid that for them to be useful, we'll need to switch all code to them, including library code, otherwise they won't be able to deliver significant static analysis improvement.
IYasha 3y ago
C++ is becoming too safe. I guess I have to move to C to stay in shape!
- burjui 3y ago
  In contrary, you should stay with C++ to stay in shape. C is too simple (comparatively) to keep your mind sharp. You want what, a pleasant programming experience, like a sissy, or constant hard ass-pounding and mind games that make a real man?
deterministic 3y ago
Profiles is a very practical solution to a hard problem. A great idea IMHO.

67 points by wyldfire 3y ago

[dead]

I like the practicality of this. I know everyone (particularly here) is excited about new languages, and some of them are great. I'm learning some myself. But there's billions (?) of lines of existing C++. For those projects, there are two options: (1) improve compiler static analysis, possibly incrementally update it with something like 'profiles'. (2) Do nothing. There is no "rewrite it in another language" option. Those are your choices, and even (1) is a stretch. So I do think we should be moving forward on both fronts - improve C++ so that existing code can be made safer, as well as push the envelope with newer safer languages.

r0ze-at-hn 3y ago
Option 3) Most businesses have a lifetime, most software has a lifetime, and one day they are run for the very last time. The same will happen for code written in C++, most of it will simply die. Some might live on in a GitHub repository, never to be compiled again. Option 4) The business core is turned into a library. Everything from the command line tools to UI all wrap this in other languages. Everything that is not the core is deleted. With the C++ committee after the last two decades I am firmly in the I'll believe [shiny feature] when I see it camp.
- pjmlp 3y ago
  COBOL 2023 was just ratified, so C++ still quite a road ahead of itself even if we rewrite everything starting today.
tobias12345 3y ago
> There is no "rewrite it in another language" option. How about "Wrap your C++ code in FFI wrappers and use it from a safer language"? It is conceptually not much different to "rewrite all your C++ code to be profile compliant" -- which will involve wrapping existing "unsafe" C++ code you can not just port over to mark it up in such a way that tooling can reason about it better.

lelanthran 3y ago

He's right in many ways. They did the best they could at the time under the constraints that they had - try adding type-safety to K&R C while maintaining backwards compatibility with K&R C. But now the only way forward I see for C++ to maintain its position as a mainstream language is to draw a hard line in the sand and effectively only keep all of the stuff that people refer to when they say "write in Modern C++", and remove everything else.

AlotOfReading 3y ago
That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For another, the error messages that can be emitted are terrible. Worse, it relies on the compiler to do a lot of heavy lifting that just isn't going to happen in the industries it's needed most for years. It's also opt-in rather than opt-out. Depending on the as-yet(?) unclarified constraints on UB, there may be yet more footguns for those unwise enough to attempt incremental rewrites. Also, because it's C++ there are already a bunch of visual warts like having to continue using gsl::span instead of std::span because of subtly different semantics. Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings.
- lelanthran 3y ago
  > That's effectively what the profiles proposal is: a set of compiler warnings that error if you use anything outside a limited subset of modern C++. Subtly different - by "a line in the sand" I meant that anything past this line is New C++ and anything behind the line is Old C++. Your compiler for New C++ wouldn't compile anything that is Old C++, and the Old C++ compiler wouldn't compiler much of New C++. Two different languages that both have Current C++ as an ancestor. > I don't think it's a very good proposal, personally. For one thing, it effectively amounts to a rewrite of nearly all existing code. For making it a set of errors in the Current C++, yes, it's a bad proposal and not what I proposed. Under my proposal, it's not like your Old C++ compiler will suddenly stop existing, or stop being supported, would it? You'll effectively have decades before this is the case. > Or you can use a memory safe language and get essentially the same/better guarantees without all the caveats. However, you have to list a different language on future job postings. Yeah. You list either New C++ or Old C++ (or both, if you can). Like many others, I gave up on C++ a long time ago and stick with C for those projects that I both 1) do solo, AND, 2) need the low-level access and performance.

hyperman1 3y ago

As ssoneone who used to like C++ but has moved on to rust: There are good things in here, but I am not convinced they go far enough, even if completely implemented. The good: I see a new Stroustrup. At the time of the NSA report, he seemed to be in denial about the position C++ was in, security wise. The 'just be carefull'- wont-scale slide seems a much better basis to start the discussion from.He seems to propose something similar to rust editions, allowing problematic parts of the language to be switched off, with an escape hatch similar to unsafe. If this would work out, rewrite it in rust could no longer be needed. There is an upgrade path for C++, and an incentive to use it. The bad: There seems to be still some denial in there. I see rust providing today what he calls a fantasy. In fact, it existed before C with languages like ADA, except the ecosystem just wasnt there. Second problem is the timeline. 3 years for a new language version, then 10 years for the ecosystem to upgrade, then another 10 years until everyone is convinced this new way of working should be better? It seems both an aggressive timeline and a promise it wont happen in my professional lifetime. Also, a path forward is not a commitment, e.g. to completely eradicate undefined behavior outside unsafe blocks. All and all, and I hope I am wrong here, I read this as too little, too late. Rewriting it all from scratch is hard, but erasing the culture of the C++ ecosystem seems a lot harder.

nyanpasu64 3y ago
Rust solves some problems of C++ (memory safety for common-cases of code) while introducing new problems (less expressive safe code and harder-to-write unsafe code, expanded UB when trying to expose &mut to safe code from raw pointers, or RefCell runtime panics).
- saghm 3y ago
  I don't disagree about unsafe Rust being trickier than people might realize, but "RefCell runtime panics" bring a "new" problem is a bit of a stretch; it's strictly better than UB, which can also crash. Making a situation that used to be "maybe crash, maybe accidentally continue running and make things far wise than crashing" instead "definitely crash" is a reduction of an existing problem rather than a new one.

zamalek 3y ago

I really hope that this yields fruit. I'll never touch the language again myself, but we need to get the hardcore C++ fans on board. However, > By the time it happens — 40 years from now — we’ll probably have 20 different ones, and they have to interoperate. C++ doesn't interoperate with anything either due to name mangling being unspecified.

GoblinSlayer 3y ago
C/C++ can't even interoperate with itself due to varying text encodings, integer sizes, different file system capabilities, fork and stuff like that.

jokoon 3y ago

I love c++, but honestly I see less reasons to use it instead of slower things like python ruby etc. C++ is just too slow to compile and it's really not nice to use. C++ is great to write libraries that need to be fast, but in general, most of what people write should be in interpreted languages, and when speed really matters, use C++ to remove bottlenecks. Most of software doesn't need to be written in C++.

GoblinSlayer 3y ago
False dichotomy fallacy, C++ and python are not the only languages.
burjui 3y ago
As if C++ was the only statically typed language compiled to native code.

tobias12345 3y ago

I am disappointed: I have to wait a few years for the C++ committee to define profiles. Then a few more years for tooling to become available. Then a few more months for the tooling to become interoperable enough to actually be used in existing build tooling. Then a few more years for all my major dependencies to actually use profiles. Then I can rewrite my code in profiles-C++ -- or by writing safety wrappers around my existing code and all dependencies that do not support the right profiles. Or I can switch to a memory safe language today. I still have to write safety wrappers around all my code to interface with that, but I'll have a couple of years of a head-start to anybody sticking to C++.

pjmlp 3y ago
Not everyone has that option, thus we need to also improve C and C++. As an example, while Microsoft slowly adopts Rust, it keeps putting out best practices and improved tooling, they aren't going to rewrite the whole Windows, XBox and Azure C++ code into Rust for the next couple of decades, or how long they would still matter on the market place. Or Apple with they increased adoption of Swift, while still having to deliver C, C++, Objective-C and Objective-C++ stuff. Or Google slowly adopting Rust, yet it still isn't officially supported on the NDK, or being the main language used on V8.
- tobias12345 3y ago
  Which option? To write wrappers now instead of later? I just see no way to be able to use current C++ code in a profiles world without wrappers or even a rewrite. For some code with decent semantics, a modern enough code base and clean APIs that wrapper might be just slapping a "compatible with profile FooBar" somewhere. On the other hand those are the APIs that are the easiest to wrap for other languages, too. > As an example, while Microsoft slowly adopts Rust, it keeps putting out best practices and improved tooling, they aren't going to rewrite the whole Windows, XBox and Azure C++ code into Rust for the next couple of decades, or how long they would still matter on the market place. So they are making the jump away from C++ now, wrapping their existing code to reuse it from safer languages. Smart :-)

cvalka 3y ago

The guy needs to burn in hell.

dang 3y ago
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

gemstones 3y ago

I think it's realistic to expect this to be the work of decades! Great talk by Bjarne. Will attrition make a decades-long timeline viable? I'd never touch C++ myself, I'm too scared there will be a long period of time where I'd be actively dangerous and introduce security holes. I am learning Rust, because that type of low-level systems programming seems like a valuable thing to have. Are there young devs who aspire to go through the C++ learning curve? I'd love to hear about your experience!

pomatic 3y ago

Am I an idiot? Re-working language definitions and compilers is _hard_. Instead, why not accept there are flaws and try to catch/fix them? I can see two obvious paths (I'm sure there are more) to address (N.P.I) these issues - top down: AI based code review. Wouldn't that catch 80%+ of common errors? Bottom up: Aggressive hardware fencing of memory access, much finer grained than pages? What am I missing?

burjui 3y ago
If you need a superhuman intellect (admittedly, a narrow one) in order to write sane code in a language, that means that language is no longer a good language for humans. The current trend of slapping an AI onto everything makes me nervous about our future: why put effort into careful design when it's easier to feed terabytes of data to an AI and hope something good comes out? Nevermind that you now have to sift through tons of garbage it produces. C++ is deeply flawed to say the least, you won't fix it with AI or anything. It's time to ditch it already.

afdbcreid 3y ago

I'm skeptical of profiles-C++. I'm afraid that for them to be useful, we'll need to switch all code to them, including library code, otherwise they won't be able to deliver significant static analysis improvement.

IYasha 3y ago

C++ is becoming too safe. I guess I have to move to C to stay in shape!

burjui 3y ago
In contrary, you should stay with C++ to stay in shape. C is too simple (comparatively) to keep your mind sharp. You want what, a pleasant programming experience, like a sissy, or constant hard ass-pounding and mind games that make a real man?

deterministic 3y ago

Profiles is a very practical solution to a hard problem. A great idea IMHO.