So, do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go?
> do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go?
Yes, yes. Obviously the Rust ecosystem has fewer mature libraries, but its type system and error handling make Go look like a toy.
Go can be okay for small one-off tools, but its safety guarantees are not far ahead of scripting languages and I think it should be considered as such.
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.
^1: Most people report being productive with Go in a day or two
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.
Go is good to get things done quickly. It has a vast ecosystem and super-fast compilation. It's like a modern BASIC, but more performant and fun to use. It's fast enough for most everyday tasks except for real-time audio processing and high end gaming. It's good for writing CLI tools and server backend software.
Rust is good for writing libraries and CLI tools that replace existing C or C++ solutions with inherently safer versions and when speed matters a lot, though not as much as what would make you use Fortran or hand-optimized C. It is not suitable for high integrity systems and solid engineering where you'd normally use Ada/Spark, because of low maintainability, an unprofessional 'language aficionado' user base converted from C++, and being a fast moving target. Maybe later, though.
Have any new languages popped up in either of those spaces or does C++ still reign supreme?