So I've been writing #Rust code for roughly 4-8 hours a day for a contract I'm working on. It has _massively_ increased my understanding and fluency of the language. I am far from an expert, but I've gone from a relative novice to a fairly competent Rust developer in a pretty short period of time. Here are some things I've learned:
- Yes you will wrestle with the compiler. Some of the things you wrestle over seem silly/unnecessary/annoying. What you'll realize, though, as you reason with the compiler is that what you're wrestling with your compiler over is an incredibly important issue. For example, you'll run into issues where you find yourself constantly .clone()'ing a struct. If that struct contains 3 vectors that contain a shit ton of data, every time you clone that struct... you're cloning all of the underlying data. You're going to find yourself eating up RAM for no reason. So when your compiler complains telling you that you need to clone... you should probably look into your im
... show moreSo I've been writing #Rust code for roughly 4-8 hours a day for a contract I'm working on. It has _massively_ increased my understanding and fluency of the language. I am far from an expert, but I've gone from a relative novice to a fairly competent Rust developer in a pretty short period of time. Here are some things I've learned:
- Yes you will wrestle with the compiler. Some of the things you wrestle over seem silly/unnecessary/annoying. What you'll realize, though, as you reason with the compiler is that what you're wrestling with your compiler over is an incredibly important issue. For example, you'll run into issues where you find yourself constantly .clone()'ing a struct. If that struct contains 3 vectors that contain a shit ton of data, every time you clone that struct... you're cloning all of the underlying data. You're going to find yourself eating up RAM for no reason. So when your compiler complains telling you that you need to clone... you should probably look into your implementation.
- Yes, multi-threaded/concurrent Rust is _hard_. This is because multi-threaded/concurrent approaches _should be hard_ because you're talking about tossing a ton of CPU power against a complicated problem set, very fast. Sharing memory resources between threads _should be complicated_, because if the interface is simple, you're probably going to footgun yourself somewhere.
- Rust makes you think about your implementations far more than you otherwise would. Should your function work on the object, or a pointer to an object? This matters. Should that field be public? Should it be mutable? Are you trying to work on an iterator? Should you expect the result of a function to always be the type you expect it to be (so you can just .unwrap()) or should you do error handling? These are problems you _should_ have to think about.
In all, what you realize after writing a lot of Rust is that the compiler is complex for a reason, and your wrestling with it can be incredibly productive, not just as a Rust dev but as an engineer in general.
#softwaredevelopment #softwareengineering #Rust #Rustlang #computerscience
