5 ms·

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture, and th

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen minute bagpipe dirge your lead single it doesn't really matter whether you use the colored vinyl.

topspin 1y ago
> I am actually much more pessimistic about Profiles than Simone. Likewise. Apparently Stroustrup wrote his first Profiles paper two years before HN existed. That's an incubation period long enough to wonder about its value, for multiple values of "value."
- phatskat 1y ago
  I’m very disconnected from the C/++ world, so when I was reading about profiles in another comment here (the one about the committee essentially saying “Safe C++ is off the table”), profiles sounded like something that was in an early phase of planning and implementation. Then the linked Reddit thread mentioned them being a thing in 2015 and I thought “oof they’ve been on profiles for a minute and it’s this underdeveloped?” and now your comment - yikes! There was a time when I was learning programming where my options were what the library offered: books on C/++, Java, obscure X extensions, Assembly, and BASIC. I quickly found that C just didn’t “click” for me and the JRE/JDK was a real pain to work with on a slow internet connection and no guidance. The only thing that’s made me want to go back to trying systems programming is the existence of Rust - I like the concept of the borrow checker and the added safety in general, and the community I’ve seen online seems a lot more inviting and friendly than I ever felt trying to find C++ resources. All that said, the conversation around core safety in C++ and the community’s reaction to “workarounds” (like offloading functionality to Rust) makes me want to just never step back in to that particular world. There’s no appeal I can see about loading a footgun and putting on a blindfold unless you need to work in that world.
kazinator 1y ago
The first four letters of "culture" are certainly right.
dana321 1y ago
Rust has safety culture? Not in the wild, a lot of coders seem to think its cool to use unsafe to get an extra hairpin of performance at the cost of safety
efuquen 1y ago
And I would say the deficiencies in Profiles and the fact Safe C++ was killed is the technical decisions reflecting the culture problem.
Henrystewart 1y ago
[dead]
AlotOfReading 1y ago
It doesn't show up in the online videos, but there was a huge contingent of people at that fireside chat wanting a reasonable safety story for C++. The committee simply doesn't have representation from those people and don't seem to understand why it's an existential risk to the language community. The delivery timelines are so long here that anything not standardized soon isn't going to arrive for a decade or more. That's all the time in the world for Rust (or even Zig) to break down the remaining barriers. Profiles and sanitizers just aren't sufficient.
- krater23 1y ago
  Sorry man, but I work since 2012 in professional security development in C/C++. Normally no one talks anymore about things like buffer overflows, use after free,... since years. Everyone uses tools to check for this, and in the end it's cheaper than using Rust. The attack vectors we talk about are logic errors and wrong usage of crypto. Things that can happen with Bash, C/C++, Rust and any other language and that you can't check automatically. Additionally to that, we talk about supply chain attacks, a thing that Rust with Cargo falls deep into. But, based on a initiative of some Rust entusiast of one Team we tried it. Result after a half of a year was to not to use it. Learning a new language is difficult, Rust is for much people not fun to write and a newbie Rust programmer writes worse code than a senior C/C++ programmer, even if it's the same person. Beside of people hyped by Rust, there is not much interest to replace C/C++. Currently I see no existential risk at all. On the other hand, Rust currently is overhyped, I would not bet that it's easy to find long time experienced Rust developers to maintain your code in a decade.
  - maleldil 1y ago
    > Normally no one talks anymore about things like buffer overflows, use after free,... since years Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.
    - m3047 1y ago
pizlonator 1y ago
> The profiles technology isn't very good. Can you be very specific about why? Here's the argument for why profiles might work: with all of the profiles enabled, you are only allowed to use the safe subset of C++ and all of the unsafe stuff is hidden behind APIs whose implementations don't have those profiles enabled. Those projects that enable all profiles by default effectively get Swift-like or Rust-like protection. Like, you could force all array operations to use C++ stdlib primitives, enable full hardening of the stdlib, and then have bounds safety. And you could force all lifetime operations to use C++ stdlib refcounting primitives, and then have lifetime safety in a Swift-like way (i.e. eager refcounting everywhere). I can imagine how this falls over but then it might just be a matter of engineering to make it not fall over. (I'm playing devils advocate a bit since I prefer Fil-C++.)
- seanbax 1y ago
  I illustrate why it won't work with a number of examples here: https://www.circle-lang.org/draft-profiles.html https://www.circle-lang.org/draft-profiles.html To address your points: 1. The safe subset of C++ is too small to do anything with. 2. The Standard Library is not written in the safe subset. My favorite example from the above paper is the problem of std::sort -- the compiler has no idea if both operands are iterators into the same allocation. The function is fundamentally unsafe. Which C++ profile do you turn on to make that safe? Does it ban use of std::sort? Does it ban use of all <algorithms>, all of which work on pointers/iterators that are susceptible to use-after-free UB? The whole Standard Library is unsafe. I proposed a rigorously safe std2, and that was rejected. And now you propose a safe std2 (using refcounting primitives)--why would that fare better? What does Profiles actually propose? No change in existing code. The compiler simply finds all UB. Right.
- IAmLiterallyAB 1y ago
  My limited understanding is. There is no safe subset (That's what was just discontinued, profiles are the alternative.) And C++ code simply doesn't have the necessary info to make safety decisions. Sean explains it better than I can https://www.circle-lang.org/draft-profiles.html https://www.circle-lang.org/draft-profiles.html
Animats 1y ago
Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them. DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they have a consortium of universities working on it. Not much, if anything, has come out. Disappointing. Rust is probably too hard. I write 100% safe Rust, and there are times when I hit an ownership structure wall and have to spend several days re-planning. So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. Although object-oriented programming is out of fashion, classes with inheritance are useful. It's really hard to do something comparable in Rust. Traits are not that helpful for this. Go is a good compromise. Safety at a minor cost in performance. Go is good enough for web back end stuff. Go has both GC and "green threads". This automates the problems that wear people down in C++ and Rust. [1] https://www.animats.com/papers/languages/cppstrictpointers.html https://www.animats.com/papers/languages/cppstrictpointers.h...
- deleted 1y ago
  [deleted]
- pron 1y ago
  > Go is a good compromise. Safety at a minor cost in performance. Go is good enough for web back end stuff. Go has both GC and "green threads". Or, for even better performance, you can use Java (24+), which has both "green threads" and a more advanced and performant GC and compiler than Go.
- tempodox 1y ago
  > The layers of cruft in C++ have become so deep that it's a career just to understand them. The committee have, over decades, dug themselves into a hole that they won’t be able to get out of, even if they wanted to. C++ does have some features that I appreciate, but for every new project I begin it has to contend with Rust and OCaml, and most of the time it loses. It will stay relevant for existing projects, but becoming the language of choice for new projects will only get harder with time.
- 1y ago
jcranmer 1y ago
C and C++ are fundamentally memory-unsafe languages. That doesn't make them bad languages, but it is a reality that you have to face when you work with them. And one of the things we've learned is that building safe abstractions, while not a complete solution, does quite a long way. And then CISA suggested that "maybe we should stop using memory-unsafe languages." And this has some of the C++ committee utterly terrified; they need something that lets them tell the government that C++, today, is memory-safe. That thing is C++ profiles. It's not about actually making C++ memory-safe, it's about being able to check the box that C++ is memory-safe, and this is so important it needs to be voted into the standards yesterday and why are you guys saying mean things about C++ profiles... C++ profiles is a magic solution to the problem. As one committee member noted, there's not enough description of profiles yet to even figure out if it can be implemented or not. Instead, it's just a vague, well, compile with -fsanitize=address, compile with fortify-source, use hardened malloc, that makes my code memory-safe, right? And for as long as profiles remains a magic solution to check a box, it will remain vaporware in practice. One of the real risks I see in the C++ committee is that they seem to want to drive all of the implementers out of the room.
- pjmlp 1y ago
  Spot on, since C++11 the committee has increasingly started to design and add features to the standard without any kind of implementation, only after the standard gets ratified, the implementers eventually find out that the design is broken, or has flaws. A strange phenomenon akin to the Algol 68 days, and no other ISO based language is taking, where standardising existing practice or having a full test implementation is still pretty much what it being done. How many export templates, GC, type traits defect fixes, volatile behaviour changes, modules, contracts,.... can implementers still put up with?
  - murderfs 1y ago
    The committee got burned, extremely badly, by C++03's export templates, where it got standardized without an implementation, and everyone realized it was basically unimplementable, and the only group that did, wrote a paper telling everyone not to [1] This was well in mind when C++11 came around (especially since C++11 slipped so badly: it was originally "C++0x", and then they ran out of digits for x). By the time we hit C++20, I think the lessons were lost, especially when it came to there being two competing modules implementations and the committee deciding to select neither. 1: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n14...
Voultapher 1y ago
I came to the same conclusion in a talk I gave to the Munich C++ Meetup [1]. There is a prevalent culture of expecting users to not make mistakes. Library constructs that could be significantly safer-to-use are kept easy-to-use incorrectly, usually with the argument of performance. The irony is that if you look closer, the performance optimization that was done is removing the seatbelts from a small hatchback to safe on weight. [1] https://youtu.be/rZ7QQWKP8Rk https://youtu.be/rZ7QQWKP8Rk or text form https://github.com/Voultapher/Presentations/blob/main/safety-vs-performance/present.md https://github.com/Voultapher/Presentations/blob/main/safety...
- vintagedave 1y ago
  A year or so ago I read that there was a design decision railroaded through the committee about what kind of safety approach could be looked at. Its wording effectively prevented Safe C++. I was not at this meeting so I’m going on what others say: https://www.reddit.com/r/cpp/comments/1hppdzc/comment/m4jjo4m/ https://www.reddit.com/r/cpp/comments/1hppdzc/comment/m4jjo4... I’m a big fan of Safe C++ and believe its approach — learning from another language, incremental opt-in (just like all good refactorings, work on code and improve it piece by piece) — would have been the path that solved some genuine problems. Profiles seem a hodgepodge. And — to share personal worries about what I read into what comments like the above imply, this is not a statement — I worry deeply about the relationship between who proposes what, and who has pricklier personalities or less connections, with what approach was accepted. I wish Safe C++ would continue as a hard fork of the language.
  - Voultapher 1y ago
    As much as the alternatives (profiles) don't solve the issue, Safe C++ (Circle) does have substantial issues as well. You need a separate and largely incompatible standard library, including containers. Generic code (templates) is largely left unsolved on a conceptual level so far. At this point incrementally replacing parts of your code with Rust - which has a mature ecosystem and tooling, remember if you want provable safety none of your dependencies used in Safe C++ code are allowed to be unsafe - is going to be less hassle. Firefox showed you can do it, and even Microsoft is choosing that path for the Windows kernel. Waiting for Safe C++ to be usable, seems like wanting to wait for a worse Rust. Interop is hardly going to be much better than bindings generated by cxx.
pjmlp 1y ago
As discussed multiple times, I agree with the sentiment. I think we are reaching a phase where C++ won't be going away, as it is quite relevant in many fields, however the two languages approach will keep increasing, and many will consider C++26 good enough for such scenarios. C++26 and not lower, due to reflection. I am certain anything else beyond C++26 will only be considered by hardcore C++ shops that culturally won't ever use anything else, besides scripting for builds and OS automation tasks.

topspin 1y ago

> I am actually much more pessimistic about Profiles than Simone. Likewise. Apparently Stroustrup wrote his first Profiles paper two years before HN existed. That's an incubation period long enough to wonder about its value, for multiple values of "value."

phatskat 1y ago
I’m very disconnected from the C/++ world, so when I was reading about profiles in another comment here (the one about the committee essentially saying “Safe C++ is off the table”), profiles sounded like something that was in an early phase of planning and implementation. Then the linked Reddit thread mentioned them being a thing in 2015 and I thought “oof they’ve been on profiles for a minute and it’s this underdeveloped?” and now your comment - yikes! There was a time when I was learning programming where my options were what the library offered: books on C/++, Java, obscure X extensions, Assembly, and BASIC. I quickly found that C just didn’t “click” for me and the JRE/JDK was a real pain to work with on a slow internet connection and no guidance. The only thing that’s made me want to go back to trying systems programming is the existence of Rust - I like the concept of the borrow checker and the added safety in general, and the community I’ve seen online seems a lot more inviting and friendly than I ever felt trying to find C++ resources. All that said, the conversation around core safety in C++ and the community’s reaction to “workarounds” (like offloading functionality to Rust) makes me want to just never step back in to that particular world. There’s no appeal I can see about loading a footgun and putting on a blindfold unless you need to work in that world.

kazinator 1y ago

The first four letters of "culture" are certainly right.

dana321 1y ago

Rust has safety culture? Not in the wild, a lot of coders seem to think its cool to use unsafe to get an extra hairpin of performance at the cost of safety

efuquen 1y ago

And I would say the deficiencies in Profiles and the fact Safe C++ was killed is the technical decisions reflecting the culture problem.

Henrystewart 1y ago

[dead]

AlotOfReading 1y ago

It doesn't show up in the online videos, but there was a huge contingent of people at that fireside chat wanting a reasonable safety story for C++. The committee simply doesn't have representation from those people and don't seem to understand why it's an existential risk to the language community. The delivery timelines are so long here that anything not standardized soon isn't going to arrive for a decade or more. That's all the time in the world for Rust (or even Zig) to break down the remaining barriers. Profiles and sanitizers just aren't sufficient.

krater23 1y ago
Sorry man, but I work since 2012 in professional security development in C/C++. Normally no one talks anymore about things like buffer overflows, use after free,... since years. Everyone uses tools to check for this, and in the end it's cheaper than using Rust. The attack vectors we talk about are logic errors and wrong usage of crypto. Things that can happen with Bash, C/C++, Rust and any other language and that you can't check automatically. Additionally to that, we talk about supply chain attacks, a thing that Rust with Cargo falls deep into. But, based on a initiative of some Rust entusiast of one Team we tried it. Result after a half of a year was to not to use it. Learning a new language is difficult, Rust is for much people not fun to write and a newbie Rust programmer writes worse code than a senior C/C++ programmer, even if it's the same person. Beside of people hyped by Rust, there is not much interest to replace C/C++. Currently I see no existential risk at all. On the other hand, Rust currently is overhyped, I would not bet that it's easy to find long time experienced Rust developers to maintain your code in a decade.
- maleldil 1y ago
  > Normally no one talks anymore about things like buffer overflows, use after free,... since years Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.
  - m3047 1y ago

pizlonator 1y ago

> The profiles technology isn't very good. Can you be very specific about why? Here's the argument for why profiles might work: with all of the profiles enabled, you are only allowed to use the safe subset of C++ and all of the unsafe stuff is hidden behind APIs whose implementations don't have those profiles enabled. Those projects that enable all profiles by default effectively get Swift-like or Rust-like protection. Like, you could force all array operations to use C++ stdlib primitives, enable full hardening of the stdlib, and then have bounds safety. And you could force all lifetime operations to use C++ stdlib refcounting primitives, and then have lifetime safety in a Swift-like way (i.e. eager refcounting everywhere). I can imagine how this falls over but then it might just be a matter of engineering to make it not fall over. (I'm playing devils advocate a bit since I prefer Fil-C++.)

seanbax 1y ago
I illustrate why it won't work with a number of examples here: https://www.circle-lang.org/draft-profiles.html https://www.circle-lang.org/draft-profiles.html To address your points: 1. The safe subset of C++ is too small to do anything with. 2. The Standard Library is not written in the safe subset. My favorite example from the above paper is the problem of std::sort -- the compiler has no idea if both operands are iterators into the same allocation. The function is fundamentally unsafe. Which C++ profile do you turn on to make that safe? Does it ban use of std::sort? Does it ban use of all <algorithms>, all of which work on pointers/iterators that are susceptible to use-after-free UB? The whole Standard Library is unsafe. I proposed a rigorously safe std2, and that was rejected. And now you propose a safe std2 (using refcounting primitives)--why would that fare better? What does Profiles actually propose? No change in existing code. The compiler simply finds all UB. Right.
IAmLiterallyAB 1y ago
My limited understanding is. There is no safe subset (That's what was just discontinued, profiles are the alternative.) And C++ code simply doesn't have the necessary info to make safety decisions. Sean explains it better than I can https://www.circle-lang.org/draft-profiles.html https://www.circle-lang.org/draft-profiles.html

Animats 1y ago

Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them. DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they have a consortium of universities working on it. Not much, if anything, has come out. Disappointing. Rust is probably too hard. I write 100% safe Rust, and there are times when I hit an ownership structure wall and have to spend several days re-planning. So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. Although object-oriented programming is out of fashion, classes with inheritance are useful. It's really hard to do something comparable in Rust. Traits are not that helpful for this. Go is a good compromise. Safety at a minor cost in performance. Go is good enough for web back end stuff. Go has both GC and "green threads". This automates the problems that wear people down in C++ and Rust. [1] https://www.animats.com/papers/languages/cppstrictpointers.html https://www.animats.com/papers/languages/cppstrictpointers.h...

deleted 1y ago
[deleted]
pron 1y ago
> Go is a good compromise. Safety at a minor cost in performance. Go is good enough for web back end stuff. Go has both GC and "green threads". Or, for even better performance, you can use Java (24+), which has both "green threads" and a more advanced and performant GC and compiler than Go.
tempodox 1y ago
> The layers of cruft in C++ have become so deep that it's a career just to understand them. The committee have, over decades, dug themselves into a hole that they won’t be able to get out of, even if they wanted to. C++ does have some features that I appreciate, but for every new project I begin it has to contend with Rust and OCaml, and most of the time it loses. It will stay relevant for existing projects, but becoming the language of choice for new projects will only get harder with time.
1y ago

jcranmer 1y ago

C and C++ are fundamentally memory-unsafe languages. That doesn't make them bad languages, but it is a reality that you have to face when you work with them. And one of the things we've learned is that building safe abstractions, while not a complete solution, does quite a long way. And then CISA suggested that "maybe we should stop using memory-unsafe languages." And this has some of the C++ committee utterly terrified; they need something that lets them tell the government that C++, today, is memory-safe. That thing is C++ profiles. It's not about actually making C++ memory-safe, it's about being able to check the box that C++ is memory-safe, and this is so important it needs to be voted into the standards yesterday and why are you guys saying mean things about C++ profiles... C++ profiles is a magic solution to the problem. As one committee member noted, there's not enough description of profiles yet to even figure out if it can be implemented or not. Instead, it's just a vague, well, compile with -fsanitize=address, compile with fortify-source, use hardened malloc, that makes my code memory-safe, right? And for as long as profiles remains a magic solution to check a box, it will remain vaporware in practice. One of the real risks I see in the C++ committee is that they seem to want to drive all of the implementers out of the room.

pjmlp 1y ago
Spot on, since C++11 the committee has increasingly started to design and add features to the standard without any kind of implementation, only after the standard gets ratified, the implementers eventually find out that the design is broken, or has flaws. A strange phenomenon akin to the Algol 68 days, and no other ISO based language is taking, where standardising existing practice or having a full test implementation is still pretty much what it being done. How many export templates, GC, type traits defect fixes, volatile behaviour changes, modules, contracts,.... can implementers still put up with?
- murderfs 1y ago
  The committee got burned, extremely badly, by C++03's export templates, where it got standardized without an implementation, and everyone realized it was basically unimplementable, and the only group that did, wrote a paper telling everyone not to [1] This was well in mind when C++11 came around (especially since C++11 slipped so badly: it was originally "C++0x", and then they ran out of digits for x). By the time we hit C++20, I think the lessons were lost, especially when it came to there being two competing modules implementations and the committee deciding to select neither. 1: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n14...

Voultapher 1y ago

I came to the same conclusion in a talk I gave to the Munich C++ Meetup [1]. There is a prevalent culture of expecting users to not make mistakes. Library constructs that could be significantly safer-to-use are kept easy-to-use incorrectly, usually with the argument of performance. The irony is that if you look closer, the performance optimization that was done is removing the seatbelts from a small hatchback to safe on weight. [1] https://youtu.be/rZ7QQWKP8Rk https://youtu.be/rZ7QQWKP8Rk or text form https://github.com/Voultapher/Presentations/blob/main/safety-vs-performance/present.md https://github.com/Voultapher/Presentations/blob/main/safety...

vintagedave 1y ago
A year or so ago I read that there was a design decision railroaded through the committee about what kind of safety approach could be looked at. Its wording effectively prevented Safe C++. I was not at this meeting so I’m going on what others say: https://www.reddit.com/r/cpp/comments/1hppdzc/comment/m4jjo4m/ https://www.reddit.com/r/cpp/comments/1hppdzc/comment/m4jjo4... I’m a big fan of Safe C++ and believe its approach — learning from another language, incremental opt-in (just like all good refactorings, work on code and improve it piece by piece) — would have been the path that solved some genuine problems. Profiles seem a hodgepodge. And — to share personal worries about what I read into what comments like the above imply, this is not a statement — I worry deeply about the relationship between who proposes what, and who has pricklier personalities or less connections, with what approach was accepted. I wish Safe C++ would continue as a hard fork of the language.
- Voultapher 1y ago
  As much as the alternatives (profiles) don't solve the issue, Safe C++ (Circle) does have substantial issues as well. You need a separate and largely incompatible standard library, including containers. Generic code (templates) is largely left unsolved on a conceptual level so far. At this point incrementally replacing parts of your code with Rust - which has a mature ecosystem and tooling, remember if you want provable safety none of your dependencies used in Safe C++ code are allowed to be unsafe - is going to be less hassle. Firefox showed you can do it, and even Microsoft is choosing that path for the Windows kernel. Waiting for Safe C++ to be usable, seems like wanting to wait for a worse Rust. Interop is hardly going to be much better than bindings generated by cxx.

pjmlp 1y ago

As discussed multiple times, I agree with the sentiment. I think we are reaching a phase where C++ won't be going away, as it is quite relevant in many fields, however the two languages approach will keep increasing, and many will consider C++26 good enough for such scenarios. C++26 and not lower, due to reflection. I am certain anything else beyond C++26 will only be considered by hardcore C++ shops that culturally won't ever use anything else, besides scripting for builds and OS automation tasks.