They both came on the scene at the same time, aiming for similar (though not exactly the same) markets, with Go aiming for something between a "better C" and "statically-compiled Python" and Rust a straight-up "better/safer C++". There's enough overlap between those two markets that it's natural for people to want to compare the two languages and how they've evolved over time.
To be clear Mozilla first mentioned starting sponsorship for something called "Rust" a few months after Go was publicly announced. However that prototype "Rust" was a language almost entirely unlike Rust 1.0 (which didn't appear until 2015, five years after sponsorship was first announced). Go was already years into development before being announced and was used internally before the public 1.0 release.
Today Rust and Go exist in different spaces. Go is a Python/Ruby/Java/etc alternative. Whereas Rust is an alternative to C/C++/etc. Obviously there is overlap between those sets of languages but that doesn't really mean Rust and Go are as directly comparable as HN comments might lead people to believe.
>Today Rust and Go exist in different spaces. Go is a Python/Ruby/Java/etc alternative. Whereas Rust is an alternative to C/C++/etc.
You make it sound as if Python/Ruby/Java on one hand and C/C++ on the other are two well established, well delineated language blocks with completely different uses cases. That's never been the case in my experience, especially with the pair Java vs. C++ which might be the most apt comparison for Go vs. Rust.
It's absolutely obvious to me that Go and Rust are competing for market share, there's no reason why ripgrep couldn't be written in Go or fzf in Rust for instance.
Maybe it's irrelevant and there's enough room for both languages to coexist and thrive in the long term, but in my experience they really don't exist in different spaces at all.
> Go is a Python/Ruby/Java/etc alternative. Whereas Rust is an alternative to C/C++/etc
Except that in this years Rust survey, there were more people using Rust for "Backend Development" than any other purpose. Rust allows you low-level control, but in many ways it's higher-level than Go (it allows for more sophisticated abstractions that can be wrapped up in libraries). It's an excellent choice for web services. And many people find it more productive than Go (although the reverse is also true).
I would say that Rust and Go started in a similar space, but diverged over time, with Go finding a higher-level, less strict niche and Rust finding a lower-level, stricter niche. In retrospect this seems completely unsurprising, with the development team of Go primarily targeting servers and the development team of Rust primarily targeting Web browser engines (though, as both are general-purpose languages, they can be used in many niches, and plenty of people are productive with e.g. emulators in Go and servers in Rust).
Personally I find Rust to be a much higher level language than Go, though I understand this is a bit of a weird case since it also involves manual memory management to some degree.
In terms of “feeling”, Go feels like a polished form of C to me. Rust doesn’t feel like C++ to me — it actually feels much more like OCaml and even Haskell. Though Haskel no doubt has a more sophisticated type system, I still find that a shocking number of design practices that I used in Haskell port naturally to Rust.
The original Rust compiler was written in OCaml, and OCaml was one of the chief design inspirations for the language. The similarities between Rust and ML-like languages is no coincidence.
I don't understand people trying to make "a language that does it all". There has been a lot of that in Go, in Rust, in JavaScript, in Java, in TypeScript, in C++, in Haskell, in D...
