Just a few warnings. Everybody when they start are “fighting with the borrow checker”. And some people are frustrated by it. But you have to see that it is a good thing. Because Rust is warning you about a whole type of bug that your old way of doing things were actually creating this kind of bug. And now rust can catch them! It’s like a guy the frustration of someone coming from a dynamic language to a typed language and being frustrated because he has a type number but now he wants it to be a string. Sure you can do that in a dynamic language but it can created all kind of bug.
And another point. Remember what the language is made for and also not made for. Yes you are going to be faster in X language for different things. But for what Rust is good at, the power it gives you, the dev experience, and the performance are amazing.
I usually would grab Typescript first for the back and then reach to Rust where speed and security safety is critical. And it’s so good to code in it.
> Rust is telling that your old way of doing things were actually creating a whole kind of bug that now rust can catch!
As an experienced C programmer learning Rust, my frustration is less "oh it prevented a bug I would have made" and more "no but its fine in this context leave me alone" :-)
Unfortunately, "it is fine in this context leave me alone" is often incorrect now or at the very least will be incorrect in the future when some other change breaks invariants that you are using to justify its correctness today. This is not always the case, but we observe very clearly that even C++ programmers using modern smart-pointer style fuck up object ownership and lifetimes.
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.
> Unfortunately, "it is fine in this context leave me alone" is often incorrect
That's a very overused argument and IMHO wrong way to sell Rust.
The reality is, even if 100% of C bugs were memory safety related, that still does not mean every C program is riddled with bugs. If that were the case, nobody would write C programs in the first place.
There is a strong selection bias in play here. You only see times where memory safety caused an issue because you get a segfault/overflow/etc but just have invisible correct behavior at all other places.
Maybe I was lucky with the people and companies I worked at, but memory safety overall has never been a big issue with our C softwares. Sure it happens from time to time, but it's definitely not any kind of plague.
Still I'm learning Rust, so why?
For me, it has to do with the library ecosystem. It's very hard to find good quality, easily pluggable, performant C libraries. You always end up having to re implement half of the data structures you need, or use sub par configuration formats just because you don't have readily available libraries.
I think this is a much more compelling, and frankly true, argument for C programmers to use Rust.
Every C program of meaningful complexity that operates on user data is riddled with bugs.
Go look at the linux kernel. Arguably the most important C program on the planet. Absolutely enormous incentive to get it correct. It is... full of bugs. Including a large number of memory safety bugs.
Or you know, sometimes the tooling just simply is inflexible and can't figure out what is it the code is trying to do. There's a reason why parsin code is a NP-complete problem.
So tell them off and carry on? Why would you care about their opinion?
Writing low-level systems code often that involves pointer arithmetic or type punning. The whole point of Rust is to be able to write such code with the iffy parts clearly delimited.
One of the things that set off the whole actix debacle was a PR removing unsafe code with the equivalent safe code was rejected, even as it was shown to cause unsoundness reachable by safe code using the framework.
Just a few warnings. Everybody when they start are “fighting with the borrow checker”. And some people are frustrated by it. But you have to see that it is a good thing. Because Rust is warning you about a whole type of bug that your old way of doing things were actually creating this kind of bug. And now rust can catch them! It’s like a guy the frustration of someone coming from a dynamic language to a typed language and being frustrated because he has a type number but now he wants it to be a string. Sure you can do that in a dynamic language but it can created all kind of bug.
And another point. Remember what the language is made for and also not made for. Yes you are going to be faster in X language for different things. But for what Rust is good at, the power it gives you, the dev experience, and the performance are amazing.
I usually would grab Typescript first for the back and then reach to Rust where speed and security safety is critical. And it’s so good to code in it.
Have fun!