The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve.
Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks.
Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to do optimizations with Go to get fast concurrent code. You pretty much get fast programs by default. This is why it is so popular.
Almost nobody builds a server from scratch in either Go or Rust. People use libraries and frameworks for that, because while the basics are easy enough to understand, getting the details wrong means security vulnerabilities and subtle, hard-to-find bugs.
So unless you're only interested in playing around, what the core language can do isn't important. When writing a server in Rust, probably the first thing you would do is pull in Tokio/Tower or similar. At which point you'll already have a better foundation than Go provides out of the box, plus all the other benefits of Rust like a proper type system.
I don’t enjoy Go very much (gave up due to err != nil exhaustion), so please enjoy your Rust.
However note that needing to pull in libraries and frameworks, make those choices, etc is explicitly more complex than Go’s approach with a very strong standard library that does most of the things you want. Besides all of the other things that’s complicated about Rust, you also need to learn the ins and outs of the ecosystem, memorize the names of a bunch of packages, remember what fits together with what from Cargo. I guess in Rust the HTTP library of choice today is “tower” and you need “tokio” so it can do IO? Can’t tell from the names, so need to memorize. The choice in Go is simple and understandable in plain English: “net/http” does HTTP things.
People build servers from scratch (net/http) in Go without frameworks all the time. If you don’t know that you should probably refrain from starting <my favorite language> vs <language I don’t know well> flamewars.
Agree, but just for the people asking themselves "why would you do that?": these are not necessarily servers accessible via the Internet, e.g. you can run godoc locally to serve your documentation, or you can serve your UI via HTTP, like e.g. the moggio music player (https://github.com/mjibson/moggio)
net/http is production ready. Performant, handles h2, terminates SSL, etc. It’s nothing like the toy HTTP severs shipped with some other languages, e.g. Python’s http.server. The standard answer to “why would you do that” is “why not”.
I think Rust at least twice as complex Go, and an order of magnitude is not unreasonable estimate. For example, there’s only `string` in Go. How many string types are there in Rust? Even a beginner must understand &str vs String. The concept of lifetimes I find easy, but that isn’t the case for everyone - and the ramifications of the borrow checker are often a “brick wall” for me.
Anyone who’s written Typescript or Python can pick up Go and write average quality Go code in a few days after going through the tour (https://go.dev/tour/list). 10 years ago, I did the tour and the next day wrote an animated GIF for the terminal. Everything I needed was in the standard library (yes, including GIF parsing), although I eventually used a package for color quantization.
If there’s a learning resource like the Go tour for Rust that can get me from zero to writing an animated gif player in a couple of days, I’d love to hear about it! So far I haven’t been able to make my way through the Rust book at an exciting pace.
Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks.
Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to do optimizations with Go to get fast concurrent code. You pretty much get fast programs by default. This is why it is so popular.