Hacker News
points by uecker 4 days ago | 0 comments
Memory safety can also be bypassed in Rust. If you want something where memory safety is guaranteed, use Fil-C but this comes at a performance cost. Or use formal verification, where then contracts can help (but C++'s complexity doesn't).
[–] saghm 4 days ago
This is like responding to someone saying that someone can die from an getting shot accidentally by a gun by saying you can also die from drinking too much water. Both of them are technically true and do happen on occasion, but one of them is not nearly as much of a risk in most circumstances, whereas the other is pretty much inherent to the most basic way of using it.
[–] uecker 4 days ago
No, I do not think that this is comparable. This just the annoying exaggeration I complain about. In reality, one can write fairly safe C code, while Rust code in practice is also far from perfectly safe and also introduces new supply chain risks.
[–] saghm 4 days ago
I don't agree at all.

> one can write fairly safe C code

In practice, pretty much every C/C++ codebase in existence has ended up having memory safety issues, even very widely used ones with a lot of scrutiny over the years.

> while Rust code in practice is also far from perfectly safe and also introduces new supply chain risks.

You're conflating "does not have one notoriously dangerous type of safety issue" and "does not have any safety issues", which is a disingenuous characterization of what I said. You were the one who introduced the comparison to memory safety in Rust and C++, and now you're moving the goalposts as an attempt to rebut my disagreement.

[–] uecker 3 days ago
I know you disagree. But I am not conflating anything. You just claim that C is unsafe and any issue we see is obviously evidence for this, while Rust is safe and any issue we see does not change this. But there is no logical argument here that makes sense. In reality, projects in both languages see issues in practice, and to decide whether the safety is much better in one or the other can only be decided by a careful analysis based on some risk model. Note that I do no deny that Rust has an advantage with regard to memory safety (and instead a huge supply chain problem), I am just saying the advantage is massively exaggerated (and the arguments are largely based on unfair comparisons and bad statistics).
[–] uecker 3 days ago
A comparison which would be more accurate in my opinion is to look at driving in the 1960: Not much have built-in safety and no compulsory seat-belts (we see many issues with C/C++ projects, often very easy to fix). One can also even claim that no driver can safely control a car in all circumstances ("not even experts can use C safely"). Yet, with modern cars and regulations, driving is much safer today than it was and can be considered reasonably safe (modern C code and modern tooling). Rust proponents claim we must give up driving with cars completely because it too dangerous (all the accidents are clear evidence) and we must switch to trams as it is impossible to steer them into some objects (and even though there are also still accidents, trams have "steering safety" and rule out a whole class of driver errors).

You don't have to agree, but this is how I see it.

[–] saghm 3 days ago
> But I am not conflating anything. You just claim that C is unsafe and any issue we see is obviously evidence for this

That is explicitly not what I'm claiming. You seem to think that I think "memory safety" is equivalent to "safety", which is what I've repeatedly told you is not what I'm saying. That's conflation. It's not clear why you'd expect me to read more details you give after repeatedly ignoring what I'm saying and putting words in my mouth that I'm not saying, so I have to assume at this point you're posturing for other readers rather than actually trying to communicate with me in any reasonable way.

[–] uecker 3 days ago
I do not think there are other readers in this thread anymore for which I could posture. You are right that I should not introduced other safety issues into the discussion. Still I am not following. Clearly contracts allow one to guarantee memory safety of a function. The original argument was that this does not count because there are ways around it, to which I responded that Rust also has ways around it. Your point seemed to be that the risks are vastly different and I think this is an exaggeration.

But maybe I am still not getting your point correctly.

[–] saghm 3 days ago
I do think the risk of memory unsafety is vastly different in Rust and C++, and it's confusing to me that this is up for debate. Even a novice Rust programmer can easily avoid ever using the unsafe parts of the language by just not typing the word "unsafe", and it's very straightforward to configure things so that any use of them in your own code is rejected. On the other hand, in practice even proficient C/C++ programmers still will write code that ends up with memory safety issues; there were two new CVEs published for use after free in Chrome just yesterday.

Yes, there can be compiler bugs that cause unsafety in safe Rust code, and it's possible to have unsafety in dependencies that leads to issues in code that otherwise looks safe, but this can happen in C++ as well. My point is that the risk of having memory unsafety from bugs that you write in your own Rust code is effectively zero if you don't ever use the unsafe keyword, and this is how most Rust code is written in practice. Most C++ code is not written in a way that produces anywhere close to this level of confidence because the language fundamentally does not support anything like that. I don't think that contracts would fundamentally change this.

[–] tkz1312 4 days ago
I was surprised to discover recently that C++ is in a pretty nice sweet spot for verification (at least at the binary level), where it has some useful type system features, but will get out of your way and generate simple ASM (without e.g. spamming bounds checks and panics everywhere as rust does).