6 ms·

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 committe

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
    Rust has unsafe, just like Java.
    - maleldil 1y ago
      On the other hand, _all_ of C++ is unsafe.
  - arkush 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. If I understand the Heartbleed bug correctly, it did not involved buffer overflows. It was a logical bug where they "trusted" the user-provided payload length (that can be much larger than the actual payload) and allocated the response buffer accordingly without zeroing it (malloc vs calloc). The "trash" in the uninitialized memory turned out to be quite valuable. "xkcd: Heartbleed Explanation": https://xkcd.com/1354/ https://xkcd.com/1354/ "Add heartbeat extension bounds check.": https://github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead https://github.com/openssl/openssl/commit/731f431497f463f3a2...
- tobias12345 1y ago
  > we talk about supply chain attacks, a thing that Rust with Cargo falls deep into. How so? By listing all dependencies in an easy to digest way? Making it hard to have a dependency does not stop devs from reusing code, it just leads to that code bing copy/pasted into code bases. I found several copies of gzip in every large C++ code base I ever looked at. Sometimes the functions get renamed, as somebody reported that linking failed when pulling in gzip as a library elsewhere. Most of the time with some patches applied. Never with documentation on where the code came from or how to update it. "Header only libraries" are taking this approach and turn it into a best practice: Just copy this file somewhere into your source tree and you are done. Even if you use proper dependencies, you typically depend on huge kitchen sink libraries that depend on the world themselves... often with the world being "vendored" (== copied into the library repository). Those hidden dependencies are the worst kind of supply chain security issue you can have as itnis costly to even know about them being there. > Currently I see no existential risk at all. I see rust as a continuation of a trend that was started with Java... C++ has lost entire markets to memory safe languages in the last 25 years, be it the enterprise applications (Java), windows software (C#) or scientific computing (python). With these markets, C++ also has lost mind share and that shows in the new features being proposed. When I visit a rust conference I am the old guy. When I go to a C++ conference I am of average age. The old guards are retiring with few new people filling up the ranks.
IshKebab 1y ago
Yeah because the committee is now people that a) really love C++, and b) don't care enough about safety to use Rust instead. I think there are plenty of people that must use C++ due to legacy, management or library reasons and they care about safety. But those people aren't going to join language committees.
- john_the_writer 1y ago
  I don't know that they don't care about safety. They just don't agree with the definition others have picked. I remember when managed code became a thing. I being an old c++ dev noted that memory was always managed. It was managed by me.
- DannyBee 1y ago
  “But those people aren't going to join language committees.” This is amusingly wrong in the worst way. In the case of c++, they were there but they left years ago when it became clear the committee didn’t see this problem as existential
  - pjmlp 1y ago
    And in the old days, as I keep telling, many of us (users) prefered C++ over C, exactly due to the safety and stronger typing.
    - DannyBee 1y ago
      Yep. You either die young or live long enough to become the villain
- gloryjulio 1y ago
  Like the google people who can't convince them and went on to create carbon?
  - motorest 1y ago
    > Like the google people who can't convince them and went on to create carbon? Lots of people in mega-companies set forth to reinvent the wheel. I think we have enough track record to understand that the likes of Google don't walk over water and some of the output is rather questionable and far from the gold standard. Appeals to authority are a logical fallacy for a reason.

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
  Rust has unsafe, just like Java.
  - maleldil 1y ago
    On the other hand, _all_ of C++ is unsafe.
- arkush 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. If I understand the Heartbleed bug correctly, it did not involved buffer overflows. It was a logical bug where they "trusted" the user-provided payload length (that can be much larger than the actual payload) and allocated the response buffer accordingly without zeroing it (malloc vs calloc). The "trash" in the uninitialized memory turned out to be quite valuable. "xkcd: Heartbleed Explanation": https://xkcd.com/1354/ https://xkcd.com/1354/ "Add heartbeat extension bounds check.": https://github.com/openssl/openssl/commit/731f431497f463f3a2a97236fe0187b11c44aead https://github.com/openssl/openssl/commit/731f431497f463f3a2...
tobias12345 1y ago
> we talk about supply chain attacks, a thing that Rust with Cargo falls deep into. How so? By listing all dependencies in an easy to digest way? Making it hard to have a dependency does not stop devs from reusing code, it just leads to that code bing copy/pasted into code bases. I found several copies of gzip in every large C++ code base I ever looked at. Sometimes the functions get renamed, as somebody reported that linking failed when pulling in gzip as a library elsewhere. Most of the time with some patches applied. Never with documentation on where the code came from or how to update it. "Header only libraries" are taking this approach and turn it into a best practice: Just copy this file somewhere into your source tree and you are done. Even if you use proper dependencies, you typically depend on huge kitchen sink libraries that depend on the world themselves... often with the world being "vendored" (== copied into the library repository). Those hidden dependencies are the worst kind of supply chain security issue you can have as itnis costly to even know about them being there. > Currently I see no existential risk at all. I see rust as a continuation of a trend that was started with Java... C++ has lost entire markets to memory safe languages in the last 25 years, be it the enterprise applications (Java), windows software (C#) or scientific computing (python). With these markets, C++ also has lost mind share and that shows in the new features being proposed. When I visit a rust conference I am the old guy. When I go to a C++ conference I am of average age. The old guards are retiring with few new people filling up the ranks.

IshKebab 1y ago

Yeah because the committee is now people that a) really love C++, and b) don't care enough about safety to use Rust instead. I think there are plenty of people that must use C++ due to legacy, management or library reasons and they care about safety. But those people aren't going to join language committees.

john_the_writer 1y ago
I don't know that they don't care about safety. They just don't agree with the definition others have picked. I remember when managed code became a thing. I being an old c++ dev noted that memory was always managed. It was managed by me.
DannyBee 1y ago
“But those people aren't going to join language committees.” This is amusingly wrong in the worst way. In the case of c++, they were there but they left years ago when it became clear the committee didn’t see this problem as existential
- pjmlp 1y ago
  And in the old days, as I keep telling, many of us (users) prefered C++ over C, exactly due to the safety and stronger typing.
  - DannyBee 1y ago
    Yep. You either die young or live long enough to become the villain
gloryjulio 1y ago
Like the google people who can't convince them and went on to create carbon?
- motorest 1y ago
  > Like the google people who can't convince them and went on to create carbon? Lots of people in mega-companies set forth to reinvent the wheel. I think we have enough track record to understand that the likes of Google don't walk over water and some of the output is rather questionable and far from the gold standard. Appeals to authority are a logical fallacy for a reason.