Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safe C++ proposal is not being continued

sibellavia.lol

Post reply on HN
Print view View original

101–110 of 226 posts

Re: Safe C++ proposal is not being continued

#101

Post by pjmlp »

tialaramex wrote: post #18

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 min…

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.

Re: Safe C++ proposal is not being continued

#102

Post by Voultapher »

WalterBright wrote: post #100
Voultapher wrote: post #98

Earlier quoted context omitted.

> 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 bou…

> 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 lo…

> 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.

Do you have good data on that? Looking at the curl and Chromium reports they show that use-after-free is their most recurring and problematic issue.

I'm sure you are aware, but I want to mention this here for other readers. Reference safety extends to things like iterators and slices in C++.

> Not following the rules of the borrow checker does not mean the program is flawed or incorrect.

At a scale of 100k+ LoC every single measured program has been shown to be flawed because of it.

Re: Safe C++ proposal is not being continued

#103

Post by throwawaymaths »

int_19h wrote: post #88
throwawaymaths wrote: post #50

Earlier quoted context omitted.

this is kinda the opposite of what i think people really want. they want an LLL with borrow checking without all of the abstractions and baggage you get in rust.

Most of those abstractions and baggage come from the need to be able to represent and propagate lifetime constraints, though.

proc macros? Optional?

Re: Safe C++ proposal is not being continued

#104

Post by pjmlp »

WalterBright wrote: post #74
IshKebab wrote: post #33

Earlier quoted context omitted.

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.

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

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.

Re: Safe C++ proposal is not being continued

#105

Post by zozbot234 »

lelanthran wrote: post #96
zozbot234 wrote: post #67

Earlier quoted context omitted.

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. There is a common perception that Rust is less productive than competing languages, but empirical research by Google and others has found this to be wrong. Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. You may spend a few hours struggling with the borro…

> Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. That works fantastically when you're rewriting something - you already have the idea and final product nailed down. It works poorly when you don't have everything nailed down and might switch a lot of stuff around, or remove stuff that isn't needed, etc.

> It works poorly when you don't have everything nailed down and might switch a lot of stuff around

If you're prototyping code you can just do defensive .clone() calls and use Rc to avoid borrow checker issues. You don't need maximum efficiency, and the added boilerplate doesn't hurt that much: in fact, it helps should you want to refactor the code later.

Re: Safe C++ proposal is not being continued

#106

Post by IshKebab »

WalterBright wrote: post #74
IshKebab wrote: post #33

Earlier quoted context omitted.

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.

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!

Re: Safe C++ proposal is not being continued

#107

Post by nechuchelo »

I do want C++ to be a safer language, but I don't think inheriting the Rust safety model is the way to go. It is in a way revolutionary but has major downsides like inability to deal with cyclic data structures without clumpsy workarounds.

I don't want to play with a plastic sword, just put it in a sheath.

Re: Safe C++ proposal is not being continued

#108

Post by pjmlp »

jcranmer wrote: post #53
tialaramex wrote: post #18

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 min…

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 terrif…

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?

Re: Safe C++ proposal is not being continued

#109

Post by pjmlp »

Animats wrote: post #39
tialaramex wrote: post #18

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 min…

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 hav…

I dislike Go's minimalism, however it fits something I have been saying for years.

Many languages that predated Java and C#, already had everything that Go offers and then some.

Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Eiffel.

Had Java and C#, just like those, had full support for AOT compilation, value types and the same low level programming capabilities, and many stuff that was still written during 2000-2010 in C or C++ would not have happened, and maybe C++11 would not have been as relevant as it was.

During that decade many people kept writing C or C++, because they lacked mainstream alternatives for AOT compiled languages, and not because they were into low level systems programming.

Re: Safe C++ proposal is not being continued

#110

Post by silon42 »

tialaramex wrote: post #57
pizlonator wrote: post #36

Earlier quoted context omitted.

> 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 protectio…

Yes I can be specific. Firstly, you need composition. Rust's safety composes. The safe Rust library for farm animals from Geoff, the safe Rust library for cooking recipes by Alice and the safe Rust library for web server by Bert together with my safe program code adds up to my safe Rust farm foods web site. By having N profiles, where N is intended to be at least five and might grow arbitrarily and be user extensible…

+1 ... Rust has done pretty much the minimal thing that one needs to write C/C++ like programs safely... things must fit together to cover all scenarios (borrow checker / mut / send / sync / bounds checking). Especially for multithreading.

C++ / profiles will not be able to do much less or much different to achieve the same goals.

Post reply on HN