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

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.

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

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.

A lot safer, judging by browser exploits.

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

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

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.

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

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.

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

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

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

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.

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

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.

https://dev.chromium.org/Home/chromium-security/bugs/using-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

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 am curious why specifically C++ 11? Could you elaborate?

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.

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.

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

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

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

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.

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.

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.