←back to thread

611 points LorenDB | 3 comments | | HN request time: 0.615s | source
Show context
socalgal2 ◴[] No.43911893[source]
I already hated C++ (having written 100s of thousands of lines of it in games and at FAANG)

I'd be curious to know what if any true fixes are coming down the line.

This talk: "To Int or to Uint, This is the Question - Alex Dathskovsky - CppCon 2024" https://www.youtube.com/watch?v=pnaZ0x9Mmm0

Seems to make it clear C++ is just broken. That said, and I wish he'd covered this, he didn't mention if the flags he brings up would warn/fix these issues.

I don't want a C++ where I have to remember 1000 rules and if I get one wrong my code is exploitable. I want a C++ where I just can't break the rules except when I explicitly opt into breaking them.

speaking of which, according to another C++ talk, something like 60% of rust crates are dependent on unsafe rust. The point isn't to diss rust. The point is that a safe C++ with opt into unsafe could be similar to rust's opt into unsafe

replies(2): >>43912606 #>>43912670 #
aw1621107 ◴[] No.43912670[source]
> speaking of which, according to another C++ talk, something like 60% of rust crates are dependent on unsafe rust.

It's probably not the source of the stats you had in mind since it's discussing something slightly different, but the Rust Foundation built a tool called Painter [0] for this kind of analysis. According to that [1]:

> As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contain significant code. Of those 127,000 crates, 24,362 make use of the unsafe keyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword. Nearly 20% of all crates have at least one instance of the unsafe keyword, a non-trivial number.

> Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries, such as C or C++.

To be honest, I would have expected that 60% number to be higher if it were counting unsafe anywhere due to unsafe in the stdlib for vocabulary types and for (presumably) common operations like iterator chains. There's also a whole other argument that the hardware is unsafe so all Rust code will depend on unsafe somewhere or another to run on actual hardware, but that's probably getting a bit into the weeds.

[0]: https://github.com/rustfoundation/painter

[1]: https://rustfoundation.org/media/unsafe-rust-in-the-wild-not...

replies(2): >>43913075 #>>43913252 #
1. Ygg2 ◴[] No.43913075[source]
> there's also a whole other argument that the hardware is unsafe so all Rust code will depend on unsafe somewhere or another to run on actual hardware, but that's probably getting a bit into the weeds.

That's not going into the weeds, by that logic (Nirvana fallacy) no language is safe, you're going to die, so why bother about anything? Just lie down and wait for bugs to eat you.

replies(1): >>43913523 #
2. aw1621107 ◴[] No.43913523[source]
Perhaps I got the quip wrong. I was basically trying to reference discussions I've seen elsewhere along the lines of "Rust is not actually memory-safe because it needs unsafe", sometimes followed by the argument you outlined. Those discussions can get a bit involved and I don't think this is a good time/place for them, so I more or less just wanted to reference it without spending much time/words on actually delving into it.
replies(1): >>43931174 #
3. ◴[] No.43931174[source]