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

41–50 of 226 posts

Re: Safe C++ proposal is not being continued

#41

Post by IAmLiterallyAB »

pizlonator wrote: post #36
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…

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

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

Re: Safe C++ proposal is not being continued

#42

Post by zevets »

tialaramex wrote: post #25
zevets wrote: post #19

Earlier quoted context omitted.

Please do this. But first: we need to take step-zero and introduce a type "r64": a "f64" that is not nan/inf. Rust has its uint-thats-not-zero - why not the same for floating point numbers??

You can write your "r64" type today. You would need a perma-unstable compiler-only feature to give your type a huge niche where the missing bit patterns would go, but otherwise there's no problem that I can see, so if you don't care about the niche it's just another crate - there is something similar called noisy_float

I can do it, and I do similar such things in C++ - but the biggest benefit of "safe defaults" is the standardization of such behaviors, and the resultant expectations/ecosystem.

Re: Safe C++ proposal is not being continued

#43

Post by flykespice »

C++ will never be safe as long as its C root persists, it doesn't matters how much freatures you add on top of C++ to make writing safe programs more convenient.

You need to take off the "inherently unsafe" C root from C++, but it wouldn't be called C++ anymore by that point.

Re: Safe C++ proposal is not being continued

#44

Post by AlotOfReading »

pizlonator wrote: post #36
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…

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

There'd be less opposition if profiles worked that way. The real goal is to define a subset that excludes 95% of the unsafe stuff, as opposed to providing hard guarantees.

Re: Safe C++ proposal is not being continued

#45

Post by coffeeaddict1 »

pizlonator wrote: post #36
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…

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

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

That's going to be a non-starter for 99% of serious C++ projects there. The performance hit is going to be way too large.

For bounds checking, sure I think the performance penalty is so small that it can be done.

Re: Safe C++ proposal is not being continued

#46

Post by debo_ »

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 think there is room for an ML with a modern toolchain story that just omits Rust's borrow checker and does something more boring. Typescript and Rust have primed a large number of developers to be open to it.

Re: Safe C++ proposal is not being continued

#47

Post by winrid »

flykespice wrote: post #43

C++ will never be safe as long as its C root persists, it doesn't matters how much freatures you add on top of C++ to make writing safe programs more convenient. You need to take off the "inherently unsafe" C root from C++, but it wouldn't be called C++ anymore by that point.

C+++ :)

Re: Safe C++ proposal is not being continued

#48

Post by pizlonator »

coffeeaddict1 wrote: post #45
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…

> 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) That's going to be a non-starter for 99% of serious C++ projects there. The performance hit is going to be way too large. For bounds checking, sure I think the performance penalty is so small that it can be done.

That would have been my first guess but WebKit's experience doing exactly this is the opposite.

See https://www.youtube.com/watch?v=RLw13wLM5Ko

Note that they also allowed other kinds of pointers so long as their use could be statically verified using very simple rules.

Re: Safe C++ proposal is not being continued

#49

Post by vlovich123 »

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…

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity.

I really don’t understand this perspective. The whole philosophy of Rust is one where you document why “unsafe” is safe. It is not and never has been a goal to make everything safe because that is an impossible goal to merge with high performance systems language because hardware itself is unsafe. It’s why the unsafe keyword exists. If that wasn’t the goal, unsafe wouldn’t.

Re: Safe C++ proposal is not being continued

#50

Post by throwawaymaths »

debo_ wrote: post #46
Animats wrote: post #39

Earlier quoted context omitted.

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 think there is room for an ML with a modern toolchain story that just omits Rust's borrow checker and does something more boring. Typescript and Rust have primed a large number of developers to be open to it.

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.
Post reply on HN