Comment by IshKebab
2 days 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.
“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.
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.
> (...) "You shouldn't be writing new code in C++ if you want guarantees".
I'm afraid context is required to actually understand what was said. For example, it can mean anything including very obvious things like stating that the committee is still working on proposals to provide guarantees and they won't feature in a standard until the work is done and a new standard is published. Which would be stating the obvious.
Love this quote. An love the intent.
1 reply →
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!
> I think D failed to gain widespread traction for other reasons though:
D's selling only proposition was providing C++11 features in a point in time between C++98 and C++11 when the C++ committee struggled to get a new standard out of the door.
Once C++11 was out, D's sales pitch was moot, and whatever wind it had in it's sail was lost and never recovered again.
It's interesting to note that Rust, in spite of all odds and also it's community, managed to put together a far more compelling sales pitch than D.
Using D does not require a garbage collector. You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations.
D has a lot of very useful features. Memory safety features are just one aspect of it.
> The awkward standard library schism.
???
Don't underestimate the backing of a large and powerful organization.
11 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.
> Why does Rust sometimes require program redesigns? Because these programs are flawed at some fundamental level.
I'm familiar with borrow checkers, as I wrote one for D.
Not following the rules of the borrow checker does not mean the program is flawed or incorrect. It just means the borrow checker is unable to prove it correct.
> D lacks the most important and hardest kind of safety and that is reference safety
I look at compilations of programming safety errors in shipped code now and then. Far and away the #1 bug is out-of-bounds array access. D has solved that problem.
BTW, if you use the optional GC in D, the program will be memory safe. No borrow checker needed.
5 replies →
> Why does Rust sometimes require program redesigns? Because these programs are flawed at some fundamental level.
Simply not true, and this stance is one of the reasons we have people talking about Rust sect.
> Because these programs are flawed at some fundamental level.
No. Programs that pass borrow checking are a strict subset of programs that are correct with respect to memory allocation; an infinite number of correct programs do not pass it. The borrow checker is a good idea, but it's (necessarily) incomplete.
Your claim is like saying that a program that uses any kind of dynamic memory allocation at all is fundamentally broken.
> Because these programs are flawed at some fundamental level.
That's a very strong statement. How do you support it with arguments?
1 reply →
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.
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.