The same reason why Go is used to write many applications where Rust is not.
- Fast compilation
- Multi platform
- Great tooling
- Good std lib
- Easy learning curve
- Fast enough for most scenarios
- Good concurrency model
- Fast compilation
- Multi platform
- Great tooling
- Good std lib
- Easy learning curve
- Fast enough for most scenarios
- Good concurrency model
With the caveat that I'm still fairly new to Go, I'm not sure that I'd call this a complete win for Go over Rust. With regards to editing tools, yes, Go's has the edge; completion, formatting, and function lookup are all still better than anything Rust has to offer, although rustfmt has come leaps and bounds from where it used to be, and RLS looks very promising. With regards to what I'll call "infrastructure" tooling (building, packaging, testing, etc.), Rust absolutely wins, hands down. Cargo is miles ahead of anything I've heard about in the Go world, which currently has multiple commonly used tools for dependency management (none of which are nearly as good as Cargo), and I've already encountered Makefiles and custom shell scripts for common building tasks that would be a breeze with Cargo in the few weeks I've been building Go. That's not to say that there might not be equally good options out there for Go, but if they exist, they don't seem to be universally used, which mitigates their usefulness.
More on a personal opinion level, I also utterly despise the way GOPATH works. I generally try to group the projects I work on by category rather than by language (i.e. ~/code/projects for side projects, ~/code/forks for open source repos I contribute to but don't maintain, ~/code/scratch for simple projects in each language I use for if I want to try out a package or something, etc.), which GOPATH is completely incompatible with, as I'd need to add each of them to my GOPATH and then put all my Go projects of each type into a "src" directory in each of them and then either move all my non-Go projects there or have a bunch of Go-specific directories littered around in each of them. If I don't put my Go projects in a ":src" directory inside one of the paths on my GOPATH, then I can't use gorename to change the name of a variable or function, which is frankly ridiculous. This isn't to say that my way of organizing my projects is the "best" way, but I feel like enforcing a directory structure outside of the project that the tool is being used in is borderline hostile to the user.
In return, you spend more time debugging since there are no interesting static guarantees.
- Multi platform
So is Rust? Even if it weren't, you've already tied yourself to the platform support of Rust at this point.
- Great tooling
Not familiar enough to comment on this one.
- Good std lib
I can't take Go's stdlib seriously with the way they handle errors.
- Easy learning curve
Despite using it for a year I still have to google Go's syntax and semantics daily. By far the least consistent and hardest to learn general purpose language I have touched.
- Fast enough for most scenarios
Sure.
- Good concurrency model
This is literally just wrong. How can you claim to be serious about concurrency when you have no concept of immutability in your language?
- In return, you spend more time debugging since there are no interesting static guarantees.
I spend almost no time debugging my Go code... It generally either works correctly, or fails to compile... and in the cases where it doesn't work correctly, I'd prefer to have a test that makes it obvious what went wrong, and then make the test pass.
- - Great tooling
- Not familiar enough to comment on this one.
Go's tooling is one of the reasons I use it, esp. the very strict formatting style
- - Good std lib
- I can't take Go's stdlib seriously with the way they handle errors.
I prefer the way Go handles errors, cause it makes it so all control flow is visible by default.
- - Easy learning curve
- Despite using it for a year I still have to google Go's syntax and semantics daily. By far the least consistent and hardest to learn general purpose language I have touched.
I'd seriously question this, I was competent in the language after about a week, meaning at the point of just having to look up package specific stuff. Granted, I have a lot of background in C family languages, but still...
- - Good concurrency model
- This is literally just wrong. How can you claim to be serious about concurrency when you have no concept of immutability in your language?
Share memory by communicating, don't communicate by sharing memory. Yes, it's completely different from what most people are used to, but it's a valid paradigm. I'd go look up "communicating sequential processes" and do some reading if I were you.
I suspect the parent was referring to the fact that Go just has this as a convention, there's no static guarantee that the programmer gets it right and it is undefined behaviour if they don't (fortunately the race detector exists). Interestingly, Rust does provide guarantees about this sort of concurrency patterns, allowing one to get stronger control around sharing using Go/CSP-like channels.
On the other hand, it's fair that the convention/tooling is usually good enough; this is a stronger argument and probably a better one to be making than a dubious one about being irrelevant.
LOL this is the classic sort of condescension from the Go community that makes the programming languages community rage. There is a lot of irony here because Go is basically founded on an anti-intellectual ignoring of all previous research.