I write both Go and Rust professionally. To understand when and where to replace them, I think the best strategy is to put them in context with other languages. Before Go and Rust, I wrote Python and C++ exclusively. The only questions that really mattered when deciding between Python and C++ was whether or not a program would \*ever\* need to be performant or grow to a large size. Python, to put it bluntly, is very slow, and while particular classes of performance issues can be solved with asyncio and tasks (which just adds more problems - async coloring), it feels very much not worth the effort for a language that isn't \*trying\* to make performance a priority. Dynamic typing also has lots of benefits in terms of prototyping small applications and tools when a single person is doing all the work. Working as a team in Python on anything that requires modularity quickly turns to madness without mypy or discipline with docstrings. For these reasons only 20% of the projects I work on were a good fit for Python. The rest ended up in C++, which is not a good fit for the bottom half of that remaining 80%. C++ is verbose, it's tooling is not uniform, it has yielded many monolibraries to replace issues with the STL, backwards compatibility with C yields all sorts of great interview trivia questions... wait... why am I explaining this on r/rust? You all already know what the issues are. Go is essentially a C programmer's take on Python. It sticks to the 90% rule - we can solve 90% of problems with a single approach, and the 10% can go use something else. So you get a built in map type, a slice type, a concurrency model, etc. etc. etc. It's also compiled, has a concurrent garbage collector, a built in web server that's quite fast, and thanks to its concurrency model allows you to write synchronous libraries and asynchronous applications - so much better than asyncio when you don't need maximum performance. For these reasons, my default is Go. I can write programs in Go just as fast as I could in Python, but I can hit 60-70% of my use cases with Go instead of just the 20% I was hitting with Python. For everything else I will try to use Rust for all the benefits it provides over C++. I definitely disagree with anyone who says Rust is more productive than Go. I also have tuned Go web applications and found the QPS and degradation of latency under load to be quite impressive. For many classes of problem's however, Go isn't going to fit your high performance requirements, for those times, Rust is great. If you need a small memory footprint, need a proxy capable of withstanding DDoS attacks, write an engine for graphics or anything related to mathematical calculations, write search or data transformation tools, kernel drivers, firmware, compilers, ebpf programs - why put up with C++ or C when there's Rust? But just to clarify Go programmers and Rust programmers should be on the same side. We have two languages, that, thanks to hindsight, fix a ton of the deficiencies of what's used today. Convincing people to switch is a huge undertaking and Go has made a lot of progress there. But all of us, Go users and Rust users, are all of the "don't give in to the sunk cost fallacy" guild. When there are better languages we should make the investment and "do what's right" rather than constantly band aiding what we already have.
https://reddit.com/r/rust/comments/d532o5/why_go_and_not_rust/f0ju8lz?context=3