Hacker News Reader

> if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly

sigh Please look at the "trophy case" here: http://lcamtuf.coredump.cx/afl/

My views are the responses you'll probably get from the people who've been doing systems programming in C for the past 20 years. I don't doubt lots of common applications have memory issues. Maybe not a definite segfault but it's incredibly disingenuous to act like it's a major issue (as if writing C and C++ are similar to disarming a bomb or something). It's nonsense and the same reason I have been learning C++17's stuff rather than bothering with Rust.

I want a better argument for: 1) A C++ developer who's been writing C++ for a long time and is skilled in modern C++ who is wondering why he'd pick up Rust for user application development? I await more superfluous bindings like "Rust-Qt". 2) Porting C/C++ to Rust code (with a rather large codebase).

Every argument I've seen for Rust is: out of context, disingenuous when they compare it to other languages, or just incredibly biased. I don't think it's ironic that the majority of people I've met who have started doing Rust are bad at C and C++ and have bought into the list of features on Rust's homepage without any knowledge of anything related to them.

You're being so rude and inflammatory, for no reason. What's so frustrating is how you're convinced that everyone else is an idiot.

> it's incredibly disingenuous to act like it's a major issue

I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous?

Take a look at the OpenBSD bug - any user can kernel panic the whole host, a massive security issue. Are the OpenBSD maintainers, in your opinion, "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps they're "bad at C"?

The truth is that as code gets more complex, writing safe code becomes harder. The above is evidence that even smart and experienced people regularly cause colossal bugs that have real life implications.

> I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous?

Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.

> Take a look at the OpenBSD bug - any user can kernel panic the whole host, a massive security issue. Are the OpenBSD maintainers, in your opinion, "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps they're "bad at C"?

When was this code written ? you are comparing old C code with (non existant/hypothetic) rust code. How do you know the rust wouldn't slower ?

> The truth is that as code gets more complex, writing safe code becomes harder. The above is evidence that even smart and experienced people regularly cause colossal bugs that have real life implications.

That we completely agree on, but we learn quite a bit on how to write better code. Some of that knowledge got embedded in compilers/compilers warnings and tooling, some retrofitted in the languages themselves , some through libraries design and coding guideline etc...

My main problem with your argument is that you saying that a code written in rust today would be safer than a code written in C/C++ decades ago...That's probably true.

I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system.

> I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system.

A lot safer, judging by browser exploits.

> reflecting our current understanding and knowledge on how to build safe system...

Browser engines are more indicative of the current "understanding and knowledge of how to build safe systems" than nearly any C++ codebase in existence.

Part of the current "understanding and knowledge of how to build safe systems" is to use a memory-safe language.

Despite all the flashy tools that proponents of C and C++ claim that makes C++ as safe as Rust, it's not doing any good at stopping the exponentially-increasing amount of vulnerabilities and crashes that are being reported over the last few years.

You have no data at all to back this up. The vulnerabilities you speak of are, far more often than not, written in old-style C and C++. That doesn't make Rust a bad idea, but it does mean your claim is completely unsubstantiated.

Advocating for Rust by lying is not going to help anyone.

This is the same line of logic and statements repeated by C and C++ programmers that shortly thereafter get showed up with a list of CVEs in their 'modern C/C++' projects. Remember the recent Curl developer PR disaster?

I think it's too early to tell if rust will prove any better in the real world, which includes things like devs using unsafe sections to cope with time pressures.

Use of unsafe in Rust is not required or recommended in most, if not all situations. That said, auditing a handful of small unsafe blocks is easier than auditing an entire project.

The question then is whether large chunks in unsafe is still better than the entire program in the equivalent of unsafe (C).

Yes, it's the same line of logic because it's correct.

The claim that Rust's memory safety is sound while C++'s is not is... not really the question. The question is whether that matters in practice. C++ has certainly improved in making certain mistakes easier to avoid.

Now, I come down on the Rust side for many situations, but making unsubstantiated claims about your language of choice is exactly the problem people had with the Curl blog post. Please stop making them about Rust.

You've living in some serious denial. You were given a point that proves that your line of thought is incorrect, and you continue on to completely ignore that point by stating that it is correct. So tell us, o'wise one, why is that top C and C++ projects are continually riddled with CVEs, crashes, and other severe issues that are 90+% the fault of C and C++? Why is it that veteran, experienced C/C++ programmers are still making these same mistakes 20, 30, and even 40 years into their careers?

You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programers. A portion will, perhaps even a substantial portion, but I'd be willing to wager a far larger portion of the Rust written today will follow best practices and doesn't have to be written by expert programers. This is because the safety in Rust isn't optional, like it is with C/C++ best practices/new features.

> You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programmers

No, the argument i am trying to make is that if someone wants safe and reliable code, it's possible to buy that in C/C++ at cheaper price than to migrate to whole new language and platform.

> I'd be willing to wager a far larger portion of the Rust written today will follow best practices

Yes, as you mentioned that's by design. But i don't that the metric we should be looking at : in the group of people/team/compagny who actually care about safety and performance ( and let's be honest that group is the biggest one), what proportion will be using C++ vs rust.

> Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.

AFAIK no one's done a comprehensive survey, and it'd be hard to know for certain what someone would choose to use unsafe for until/unless they actually rewrite the code in question into Rust.

But if you look at code that is written in Rust today, I think you'll find less than 1% of the code is unsafe. [1] I think it's used for

* FFI / interfacing with C (common now, but less so the more you rewrite into Rust),

* low-level code (such as synchronization primitives and data structures), and

* a few bits of performance-sensitive code.

My gut feeling is that many of these bugs are in safe code, the "boring" 99%. The bugs would either be prevented by the compiler or turned into a panic at runtime instead of undefined behavior.

When people use unsafe, I'd like to think having to explicitly flag it as such would make authors and reviewers more careful. But certainly there's no 100% guarantee; I've seen broken unsafe Rust code in the wild already. As a small example, sqlite3::core::ResultRow::column_slice [2] is unsound; a following call to another column_* method would invalidate the returned pointer, [3] but as they all take a &self nothing prevents you from using the pointer after it's no longer valid. column_slice should take a &mut self instead. I haven't reported the bug because this buggy crate has been marked obsolete in favor of rusqlite.

[1] For a project of mine, it's found on 0.3% of non-comment-non-blank lines (23 unsafes / 7,390 lines). 13 of those were for FFI; the remaining 10 were due to my unfortunate obsession with optimizing for CPU. If anyone's done an accounting of more/larger projects, I'd be curious to hear it.

[2] http://www.madmode.com/rust-sqlite3/sqlite3/core/struct.Resu...

[3] https://www.sqlite.org/capi3ref.html#sqlite3_column_blob

> My views are the responses you'll probably get from the people who've been doing systems programming in C for the past 20 years.

I've been doing systems programming in C for 20 years. I disagree with your claim.

> Ridiculous - if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic.

I've caused segfaults in the runtimes of three major languages in the last year by running code that, from a user perspective, is completely fine.

I don't think the developers of those runtimes are "bad programmers".

I think the bad programmers are ones who state "segfault protection" as a feature of Rust because they read it on Rust's site. I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes). Even Bjarne would probably agree. He talks about the same issue at his "The Essence of C++" talk. Someone asks if he shares the blame, alongside Ritchie, for all of today's major security issues (Heartbleed is the given example). He says something similar to what I've said. Segfaults are not a major issue at all unless you're consciously doing something idiotic.

I don't disagree with you in that well-written code should make invalid memory accesses rare. And I don't disagree that, if you write good C++ (and I've stumped around here for C++ because I really didn't learn it until C++11 and have never had an environment where I didn't have the tools to write good C++), they are. But I feel, and pretty strongly, that Rust makes it a lot harder to write bad code in general. Memory protection is just one of the ways this is true.

I replied to you mostly because "you're a bad programmer if you need protection against invalid memory accesses" is rampant nonsense. Everyone needs that protection. It is at best a question of whether you need other things more. (Few people do.)

I agree, that was rather brash. They're not bad programmers. I tried to clarify that in my previous comment.

I think C++'s biggest failing is how large and convoluted it is but, in relation to the thread's question, how many beginner C++ programmers are gonna jump straight into systems programming? I sure hope the answer is 0.

I just see too many people quoting the list on Rust's homepage verbatim when I ask them about why a skilled C++ developer should pick up Rust.

But they're good features, mftb. I have to say that as an experienced (some might even say skilled) C++ developer I would go for pretty much all of them.

> I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes).

Nobody said that C++ code segfaults every 5 minutes, and accusing people of being disingenuous for saying things they never said is, well, disingenuous.

The claim is that memory safety problems are serious problems in C++ code. It's been found that memory safety problems are the leading overall cause of software security vulnerabilities [1].

[1]: https://insights.sei.cmu.edu/sei_blog/2014/08/performance-of...

>Let's be honest, you don't segfault unless you're doing something idiotic.

I disagree, segfaults can arise out of simple mistakes in rare cases that aren't always immediately obvious - let alone a segfault in a complex system.

A sign of a good language is to as much as possible make invalid states illegal by design. Why, if you can reliably check for bad memory use with the compiler, would you not do so? Toughness is no measure of coder talent, otherwise the best of us would only be using assembly for everything.

> A sign of a good language is to as much as possible make invalid states illegal by design

This is exactly the insight that will probably (if I can help it) keep me from leaving the functional language space ever again.

Even if only "bad programmers" segfault (debatable - especially depending on the type of code you are writing), most of the software written in the world is not made by amazing programmers who never segfault. It doesn't matter your opinion of the developer in question when a buffer overrun happens and your data gets stolen. Encourage people to write code with less safety at your own peril.

> (1) Ridiculous - if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly.

So let me get this straight. Is your position that Google's Chrome developers (just to name one project) are idiots? You can't hold your opinion without believing that Google, and in fact pretty much every other company that develops C++ developers, hires mostly idiots.

For the uninitiated: Google dedicates a whole cluster of machines to finding memory safety bugs in Chrome. Finding segfaults is part of their work flow.

https://dev.chromium.org/Home/chromium-security/bugs/using-c...

when I think of all the segfaults I've seen in last few years - it's usually been in some horrible bindings to unsafe C/C++

"if you need segfault protection, you're a bad programmer" is a ridiculous statement - your personal data is one unchecked buffer away from being very public

Look up the longest list of security advisories you can find, and then tally what percentage of them are based on "buffer overflow" bugs.

And those are merely the cases where such a bug caused a security hole.

Eliminating that entire class of bug suddenly sounds like a big win, doesn't it?

>"I don't think there's much incentive post C++11 to really consider porting anything (even small things) over"

I am curious why specifically C++ 11? Could you elaborate?

Let's look at Rust's homepage: - Zero-cost abstractions - C++, in my opinion, is the founding father of zero-cost abstractions. - Move semantics - we've had this since C++11. - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well. - Efficient C bindings - this had to be listed because we all know the world relies too much on C at the moment for this not to be a feature. C++ is almost a perfect superset of C, fantastic.

Modern C++ has made great strides in the direction of making writing good code a lot simpler. I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust. It's just not viable.

For an experienced C++ dev it might not seem sensible. I can appreciate your viewpoint here.

But it can become a hot place for higher-level people to do lower-level things and rapidly learn a lot, as it has for me and some other Rubyists.

> - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well.

So - we can implement threads without data races if we implement threads without data races? The reason people cite memory safety as a feature of Rust over C++ is because you get it for free, without having to do any additional work to achieve it.

> The reason people cite memory safety as a feature of Rust over C++ is because you get it for free

Nothing is free, language design is an exercise in compromise. OP might need to calm down a bit with the aggressive language, but underneath all that there is real message from people using (trying to ?) use modern C++ : The added safety you mentioned can 1) be really well approximated using modern C++ technics, 2) addressed by really well engrained coding standard and practice learned and known for a long time and doesn't apply for the in the unsafe part of rust that some of the libraries have to use. But i doesnt come at the cost of reduce expressiveness in the safe part of language, slower compiler time and high learning curve.

> - Move semantics - we've had this since C++11.

C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions.

Rust avoids the null state problem by statically omitting the constructor call (or, in the dynamic case, inserting a flag into the stack frame rather than forcing the programmer to reuse the object itself). It gains some ability to optimize by forbidding unwinding during a move.

> I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust.

That's not the goal. The goal is to provide a tool for new projects like Servo, or incremental partial rewrites like Firefox, or new infrastructure like ripgrep.

> C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions.

This doesn't sounds true to me. Can you clarify what you mean by moveable type have to have null state ?

> Rust avoids the null state problem by statically omitting the constructor call

You seems to be conflating move semantics and move optimization...

The parent correct: C++ runs destructors on all local variables, even if they have been "moved from", so it must be valid to do so. This translates into a null/"valid invalid"/sentinel state that the destructor can check to avoid truly destroying the underlying resource (which could result in double-freeing memory, or double-closing a file, or some other undefined behaviour). For instance, moving out of a unique_ptr will swap in NULL, and the destructor checks for that.

Static omission of destructors in Rust is more than just an optimisation: locals (and other values) never have their destructors run once they've been moved-from, and thus no values need null states, and moving a value doesn't have to run arbitrary code (it can be, and is, just a memcpy).

> > omitting the constructor call

Oops, too late to edit but that was meant to say "destructor."

Thanks for the detailed explanation. I appreciate it.