leavengood
commented
8 years ago While I'm sure you want to do the research yourself, I hope you don't mind if I give my perspective. For some context I was a long time Ruby developer who switched to Go as my primary language several years ago. My full-time job is primarily Go development, and I've been at this job for slightly over a year.
I've also been following Rust since before 1.0, but my only serious attempt to use it has been in the last two months or so. We had to convert between file formats at work, and the file format we were converting from did not have any Go libraries, but there were several for Rust. Since this was to be a single standalone tool with a very specific focus, it seemed trying Rust would be pretty low risk. Overall it was a big success and the tool works great.
Using Rust just makes Go's major flaws all the more obvious:
- Lack of real generics.
- Bad default package management.
Rust's generic system is really great, and traits are very much like Go's interfaces, one of my favorite Go features. While I did not have a large need for Rust generics in this small tool, there was one particular function where it was useful and I was very pleased. This particular case probably could have been handled in Go with interface{} but with the usual caveats. There are many other cases which can only be solved in Go with code generation. We all know Go needs generics but it has become the elephant in the room that we all just seem to ignore until the "magical" perfect solution is dropped from heaven.
As for packages, Rust's package manager Cargo is a really, really great tool. It does everything right pretty much, even allowing for different versions of the same crate to be used in the same binary, if needed (though that is actually a Rust feature.) Go's "package management" is a joke by comparison, and again, we all know that but everyone just cobbles together their own solution.
I was also really happy with Rust's closures and various functional language inspired pieces. Certain things which are awkward in Go are very elegant and readable in Rust. Sometimes Rust feels like Ruby to me.
Now on the bad side, Rust's style of memory management is just harder to deal with than a garbage collector. But I will say for my small tool it didn't cause as much problems as I would expect. I'm already gaining an intuition into how to properly do things in Rust, and that is even affecting how I think about my Go code.
Also at the moment I think goroutines are a better way to handle concurrency (if you need it.) Rust had green threads once but they abandoned them in favor of just normal threads. I assume this was due to the need for a runtime and Rust wants to have a very minimal runtime. Honestly I haven't tried making any sort of concurrency comparison between Go with goroutines and Rust with threads, maybe the difference isn't that bad. In addition Rust has crates like mio for non-blocking IO.
I still like Go and for the moment it will still be my primary work language. But I want to use Rust where I can, and am now working on several personal projects using it.
The choice between Go and Rust depends very much on the project, and overall I tend to agree with a lot of Rust fans who don't even consider Go and Rust competitors, as their primary focus is different. Go is great for web services and small local tools, Rust is great for lower level stuff and also small local tools.
I do I think for a tool like TMSU, Rust would actually be a great choice.
oniony
talklittle
lefth
Certain aspects of Go annoy me. I need to do some research into Rust to see if it annoys me less.