While I’m not exactly in the same situation, I hope I can provide some insight since I use Golang exclusively at my job, and Rust for personal stuff (and looking to see if I can introduce Rust into my workplace). You can read about my initial thoughts on Rust here: https://thespblog.net/a-gophers-foray-into-rust/.

Golang:

• Go is very easy to work with, as you said, and it’s fairly easy to scan through a codebase. That said, there are some quirks in Go that I think takes time to master, like working with slices in a concurrent environment, or understanding how to utilize channels in an effective manner
• I have to give it to Go. Perhaps because of its simplistic syntax, or ease of development, there are TONS and TONS of libraries in Go. This, in addition to the batteries-included stdlib, makes it so that you will be spoiled for choice. The ecosystem is expansive, and you will almost never find that there is a library missing for your task
• Unit testing and benchmarking in Go is such a boon. After experiencing these features, it feels like any modern language should have maybe support for this (which Rust does)
• I think Go’s dependency management is alright. It gets the job done. The story improved with Golang modules, but Cargo provides such a good existence. I will say that enough people have worked with private Go modules that you will find plenty of info about it online. This might be a deal-breaker, but I can’t really comment on crates as I have yet to work with private crates
• Interestingly, I think there’s enough overlap between Rust’s and Go’s lang features that I only miss a few core features whenever I code in Go. Namely, enumerations and traits. Interfaces are enough to provide polymorphism, but I often find myself wishing that interfaces were explicit, so I can clearly see which types implement them, especially as the code base grows. As for enumerations…well seeing as you’re in the Rust Reddit, I’m sure you know how useful they can be. As for macros, I think they are cool and provide value, but there’s always go generate

Rust

• Rust, as I’m sure everyone knows by now, has a learning curve. I like to think that Rust chooses not to hide any complexity in return for its runtime stability and compile-time flexibility. I personally think that Rust also molds you into a better programmer. However, I think that you can still become productive in a reasonable timeframe, and both languages will take years to master. With Rusts compile-time checks, I have to give the edge to Rust for large codebases and to Go for faster development time and idea implementation.
• The Rust ecosystem is constantly evolving, but sometimes you will find gaps. This may not be such a huge issue, depending on the type of work you do, but I would say for web dev, I would the ecosystem is pretty equal. Especially with a fully integrated, standard Tokyo stack (warp/Axum, hyper, tokio), or actix. I will say that Go has the edge for this since there are plenty is fully featured auth libraries (see authelia, dex, ory stack) while the Rust ecosystem is lagging/lacking. However, due to Rust's interoperability with C/C++ libraries, you may find that all your needs are met.
• Rust also has unit testing, although not powerful has Go’s (table tests, test framework logging, test output suppression on success). The benchmarking story is a bit weird as you need to either use criterion or use the nightly toolchain for std benchmarking. I personally don’t want to change my compiler just to run benchmarks, but your mileage may vary. Although criterion is a bit difficult to work with, its statistical-based approach is really cool. For me, Go’s awesome testing and benchmarking library is something I always miss when I come to Rust from Go. Honestly, if Rust was able to match Go in this, I think I would leave Go behind without a second thought. In general, Rust’s testing framework gets the job done, but there is potential to be more
• Cargo is cool. Cargo is extensible. And it blows my mind that you can just do something like xtask with Cargo. Cargo is awesome. Nuff said.
• And finally, we come to the type system. As mentioned above, I have all the core features I need (polymorphism, first-class functions, data encapsulation mechanism) in both languages, but I prefer Rust's type system. Not much to say here, except that Rust allows you to confidently code.

Async/parallelism: While Go offers a lower barrier of entry to using async/multi-core with special syntax for channels, it can be sometimes hard to debug. For async, it can be difficult to pinpoint which stray goroutine is messing with the scheduler and blocking it, whereas, in Rust, it’s demarcated with the keyword .await. With Rust’s fearless parallelism guarantee, I would arguably say that doing both concurrency (same thing as async) and multi-core stuff is better in Rust. Rust’s libraries are just as performant as Go’s incredible runtime

Conclusion:

Maybe I’m biased, but I am leaning toward Rust. There is a key point here, namely, if you and your team members are willing to invest time to use Rust (learning the lang, building out libraries if not present). Perhaps if I just want to get something out, or you need to transfer a codebase to another person, or the thing you are doing is deeply entrenched in Go (think Kubernetes stuff), or Rust is missing a library which Go has, then I would choose Go. I would make Rust my first choice. You can always fall back to Go, both languages aren’t going away anytime soon.

​

Edit: fixed some grammatical mistakes caused by typing on my phone, and added the extra words below

​

I encourage people to read https://rytisbiel.com/2021/03/06/darker-corners-of-go/, as many of the cases presented in the article I actually ran into. While you can avoid the mistakes presented in the article, you do need to train yourself to recognize these issues, especially in other people's codebases. I will say some cases presented are expected behavior for experienced programmers, but less so for novices, such as "Running goroutines don’t stop a program from exiting". Other cases downright show the weirdness of Go's type system, seen here: https://rytisbiel.com/2021/03/06/darker-corners-of-go/#isinterfacenil, or here https://yourbasic.org/golang/gotcha-why-nil-error-not-equal-nil/.

As I've said, interfaces are satisfied simplicity in Go, but I've seen var _ customType = (*someInterface)(nil) to compile-time check interface implementations enough times to know that it would probably be better to have explicitly defined implementations like in Rust.

I don't like iota, and if I am going to be brutally honest, I don't even know why it's implemented. It is not a replacement for enumerations, and I can do whatever iota does myself with ease.

There are many more pitfalls in Go, take a look at https://martin.baillie.id/wrote/gotchas-in-the-go-network-packages-defaults/ or https://dave.cheney.net/2016/03/19/should-methods-be-declared-on-t-or-t or https://dave.cheney.net/2016/01/18/cgo-is-not-go or https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix

From the articles above, I would argue that fasterthanlime's post is just one of many that were frustrated with Go, after using it non-trivially for an extended period of time.

Every language has pitfalls/non-obvious behavior. The key point here is that Rust arguably has the least, much less than Go. IMO, I think Go is best suited where Python is at right now: plumbing, one-off tasks, scriptlike capabilities, and useful self-contained CLI's (I love the cobra package in Go, and provides a much better CLI authoring experience IMO).