2 ms·
I used to write everything in Golang, but recently ported many things to Rust, so I feel like I have a good idea here. I'd consider myself quite proficient in b
by gas9S9zw3P9c 6y ago
I used to write everything in Golang, but recently ported many things to Rust, so I feel like I have a good idea here. I'd consider myself quite proficient in both. I see Go and Rust as almost opposites.
Go is "easy" and makes you immediately productive. Like, productive on the first day. It's a great language for that reason. Compilers don't complain, no complicated generics, easy concurrency, loose interfaces, GC, etc. But this comes at a cost - it's easy to write sloppy code. Because of its flexibility, my code often suffered from concurrency bugs (don't get me started on deadlock debugging), bad abstractions, or performance issues. I felt like I was productive, but I often had to re-factor my codebases multiple times because of these issues.
Rust is the opposite. I didn't feel immediate productive, and the fight with the compiler was tough at times. But most of the time, the compiler was right and I was wrong. This typically resulted in "good" code once it compiled and I rarely had to go back and refactor my code. And of course there were no pesky concurrency bugs due to the compiler checks.
These days, I would choose Rust over go for my own projects. If I consider the time spent on debugging bugs in Go, I consider myself more productive in Rust, even if the initial code takes longer to write. However, if I was leading an engineering team, I would consider Go instead. It's much easier to pick up, and it's easier to read someone else's Go code. Reading someone else's Rust code can be hard.