If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't <i>too</i> important". You need to be far better then the replacement by providing the following:<p><pre><code> * Great Tooling ( IDEs )
* Great Libraries ( Everything and a kitchen sink )
* Better Documentation
</code></pre>
Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move. No amount of language features will pull people who are doing well at their job, currently building everything they need to, and who maintain low level systems. You have to be able to entierly replace the old systems in a completely feature-complete way that's also easy to migrate to.<p>Blog posts wont pull me away from C, tooling and docs will.
> “Safe” code is guaranteed to be 100% safe. Not statistically safe. Not safe when the compiler feels like it. As long as your code compiles, it will be safe in terms of memory safety and data-race freedom.<p>As far as I am aware, the Rust compiler has not been proved correct. So whether or not your code is correct still depends on the correctness of the compiler. Of course this is probably correct, but still not 100% guaranteed.<p>Edit: Relevant discussion - <a href="https://github.com/rust-lang/rust/issues/9883" rel="nofollow">https://github.com/rust-lang/rust/issues/9883</a>
The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Rust has other features that make it generally superior in certain (many) contexts. The safety is a nice "add-on" effect, I suppose, but my view is that constantly hyping safety as the biggest selling point is missing a mark.
We are having new languages every year. Instead of debating which language is the best, why can't we invent a way to let components implemented in different languages talk with each other easily? We have pipes, sockets and message queues, but it's never simple enough to glue everything together.
A more interesting question for me is: is there any reason why would I want to use Rust over Haskell on any task where Haskell is "fast enough"?
Stroustrup has proposed a way to add safety to C++. It's called "C++ Core Guidelines", and "GSL".<p><a href="https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines" rel="nofollow">https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-...</a><p><a href="https://github.com/Microsoft/GSL" rel="nofollow">https://github.com/Microsoft/GSL</a><p>I watched his talk -- wondering if anyone is using it. <a href="https://www.youtube.com/watch?v=1OEu9C51K2A" rel="nofollow">https://www.youtube.com/watch?v=1OEu9C51K2A</a><p>Using GSL gives adds some safety to pointers and memory allocation -- while providing the bare-metal performance that C is known for. (It still feels very low-level.)
To play the devil's advocate a bit, most of these are features you already get with C++, especially if you turn on all relevant warnings and treat them as errors. I can see the advantage of having things (sorta, given "unsafe") statically guaranteed for a shared codebase, but what are some compelling reasons to switch for personal projects?
Since this is a "vs" can i assume that rust is better in all regards to C ? As in that rust is flawless ? Or should it be "Rust vs C's Pitfalls" ?
You're so wrong that is laughably.<p>That laughably hashing functions are highly specialized implementations for a proposed problem. There is NO MORAL there.<p>I code C for living and if we can use "laughably hashing functions" to gain performance we WILL DO.