My rule of thumb is use Go by default, but if it makes sense to trade a lot of developer time for extreme performance or extreme type safety, use Rust. As with all rules of thumb, there's a lot more nuance than this, but I think it captures the big idea well enough.
Re:Go 2, here we come
by zinclozenge on Thursday November 29, 2018 @02:40PM
(#18563230)
I disagree that using rust means trading a lot of developer time. I'm as comfortable with rust as I am go, and I develop equally fast in either language. I would even say faster in Rust because of the type system.
That's quite a feat. According to the Rust developer survey, it takes many people a month or more to feel productive in Rust^1 at all much less as productive as with Go. I've been picking up Rust occassionally for 4-5 years now and I'm still not particularly productive and far less productive than I am in Go (and I come from a C++ background, so it's not like I'm a stranger to thinking about memory management and things). I suspect that you're an outlier (I may be also, but my point doesn't hinge on that).
^1: Most people report being productive with Go in a day or two
Re:Go 2, here we come
by zinclozenge on Thursday November 29, 2018 @07:59PM
(#18565698)
Well it took me longer to get comfortable with Rust than Go, and I also had to learn actix (actor style framework in rust) to do the same high concurrency programming. But once the time investment is put in, I definitely consider Rust to be the more productive language.
Once async/await stabilizes and the rest of the ecosystem catches up and becomes a little bit more ergonomic to use, I would say Rust will be in a good position.
If your desire is to accept bytes over the network and spit back bytes over network Go is going to be a pretty solid choice because that was very much the focus of it's design.
However if you want to build an application for a hard realtime environment and you either lack the space for runtime or can't handle GC pauses then maybe Rust is a better choice.
From a language perspective Go is a simple language and Rust is a complex language. The two have different tradeoffs here. Go is easy to learn, has limited pitfalls but also lacks in the power department if you need metaprogramming and abstractions to model your problem. Rust however accels in that role due to it's powerful type system and hygienic macros. The tradeoff is very apparent once you try use the two languages however, Rust is -far- more difficult to both climb the initial learning curve and has a much higher ceiling.
Fundamentally you will probably find Go is better at replacing dynamic languages though there are many cases where C/C++ was used where it's bare metal nature isn't needed and Go is a very suitable replacement. Go however has some difficulty in replacing certain usages of C/++. Namely it can't easily be used to create a shared library because of it's runtime and I/O system.
That said if you wanted to be able to replace any and all C/C++ code Rust would be a better choice as it can do anything C/C++ can with no downsides. i.e embedded systems, shared libraries, bare metal access without worrying about the green threaded execution model.
There are many other things to consider too but these are some of the important ones from someone who got into coding doing C and embedded, has since learnt both Go (and used professionally) and Rust (and used for side projects).
Subjectively I think Go is a better choice when it can do the job as it's easier and less brain intensive to just do the thing. Rust however is more "fun" to program in as it's a less mechanical endeavour and also can solve some problems you can't with Go.