Although I think much of this is technically true, I think this is wrong way to "sell" Rust to C programmers. A far better approach is to say "Rust is a completely different paradigm that you may have to learn," because when you start to use closures, iterators, etc., it definitely is. It's not C. It's OCaml is C's clothing. It will allow you to beat it into submission, but if you have to beat it there is probably a better way.
There is this belief "I know C so I know what's fast here", and, while that's sometimes true, I think it's wrong often enough re: Rust to try doing things a different way at a relatively high level. I think when you're starting off with Rust your goal should be to implement virtually everything in the dumbest/most obvious/Python-ic way possible, and then to experiment with optimization/rewrites. And while you should try the thing "You know to be fast because you know C" you should also spend that time reading how the std lib implemented a feature and leaning on the std lib, benchmarking as you go. One reason is because the paradigm is obviously different. Another is because the std lib has lots of features for common uses which are optimized very carefully, which C just doesn't have, and one shouldn't ignore/forget that.
Sure. IMO, Rust should be sold to CTOs and regulators. The fact that our industry doesn't seem to be taking memory safety seriously for applications that operate on untrusted data is frankly an embarrassment. I don't doubt that people will want to keep using the thing they are used to a like. I'm saying that we need a plan to solve memory safety as an industry.
There is this belief "I know C so I know what's fast here", and, while that's sometimes true, I think it's wrong often enough re: Rust to try doing things a different way at a relatively high level. I think when you're starting off with Rust your goal should be to implement virtually everything in the dumbest/most obvious/Python-ic way possible, and then to experiment with optimization/rewrites. And while you should try the thing "You know to be fast because you know C" you should also spend that time reading how the std lib implemented a feature and leaning on the std lib, benchmarking as you go. One reason is because the paradigm is obviously different. Another is because the std lib has lots of features for common uses which are optimized very carefully, which C just doesn't have, and one shouldn't ignore/forget that.