stmfd

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.

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.

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.

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 think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction.

I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets praised for are either: (1) Ridiculous - if you need segfault protection, you're a bad programmer (CLARIFICATION: if you act like segfault protection is some majorly useful feature, you're an imbecile who must also think writing C/C++ is like disarming a bomb - nonsense; give me a real argument for Rust that isn't: insignificant, badly contrived, already in C++, etc. - you can't convince a generation of systems programmers to drop everything to move to Rust without this). 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. Or, (2), things I've been using in C++ for the past 4 years.

Rust will definitely end up in these areas I believe but I just hope that it's not some horrible binding to a C/C++ library or something. I think backwards compatibility and current dependencies is a big thing.