Comment by AlotOfReading
5 months 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.
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.
“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
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.
1 reply →
They could also care about safety but just not like the Rust approach.
This was asked at the aforementioned chat. Andreas Weis (MISRA) responded along the lines of "You shouldn't be writing new code in C++ if you want guarantees". Might not have the identity correct, my notes aren't in front of me.
3 replies →
D adds a lot to memory safety without needing to struggle with program redesigns that Rust requires.
These include:
1. bounds checked arrays (you can still use raw pointers instead if you like)
2. default initialization
3. static checks for escaping pointers
4. optional use of pure functions
5. transitive const and immutable qualifiers
6. ranges based on slices rather than pointer pairs
I think D failed to gain widespread traction for other reasons though:
1. The use of garbage collection. If you accept GC there are many other languages you can use. If you don't want GC the only realistic option was C++. Rust doesn't rely on GC.
IIRC GC in D is optional in some way, but the story always felt murky to me and that always felt like a way of weaseling out of that problem - like if I actually started writing D I'd find all the libraries needed GC anyway.
2. The awkward standard library schism.
3. Small community compared to C++. I think it probably just didn't offer enough to overcome this, whereas Rust did. Rust also had the help of backing from a large organisation.
I don't recall anyone ever mentioning its improved safety. I had a look on Algolia back through HN and most praise is about metaprogramming or it being generally more modern and sane than C++. I couldn't find a single mention of anything to do with safety or anything on your list.
Whereas Rust shouts safety from the rooftops. Arguably too much!
15 replies →
However D still needs the ecosystem and support from platform vendors.
Unfortunately that was already lost, Java/Kotlin, Go, C# and Swift are the platform holder darlings for safe languages with GC, being improved for low level programming on each release, many with feature that you may argue that were in D first, and Rust for everything else.
Microsoft recently announced first class support for writing drivers in Rust, while I am certain that NVidia might be supportive of future Rust support on CUDA, after they get their new Python cu tiles support going across the ecosystem.
Two examples out of many others.
Language is great systems programming language, what is missing is the rest of the owl.
> With program redesigns that Rust requires
Why does Rust sometimes require program redesigns? Because these programs are flawed at some fundamental level. D lacks the most important and hardest kind of safety and that is reference safety - curiously C++ profiles also lacks any solution to that problem. A significant amount of production C++ code is riddled with UB and will never be made safe by repainting it and bounds checking.
Claiming that not being forced to fix something fundamentally broken is an advantage when talking about safety doesn't make you look like a particularly serious advocate for the topic.
10 replies →
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.
Like the google people who can't convince them and went on to create carbon?
> 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.
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.
> 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.
> > 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/
"Add heartbeat extension bounds check.":
https://github.com/openssl/openssl/commit/731f431497f463f3a2...
Rust has unsafe, just like Java.
1 reply →
> 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.