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.
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.
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).
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.
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...
Whereas Rust user and committers are much more interested in discussing what is good programming, nuances of PL theory and so on. It does not matter if the post is about Rust or not and specially if it is about Go.
If you start talking about changing the recipe for Coca-Cola, surely Pepsi is going to enter the discussion at some point, right?
The HN comments on this article have been derailed from any interesting discussion about Generics in Go to an utterly pointless religious war about Rust and type systems.
1. This opinion gets expressed on every single comment thread about Go, multiple times. Maybe have some respect for other people's right to have a discussion on a subject without derailing it with a tangential opinion about another language.
2. We all know that Rust is the one true programming language for every possible context. However, because we're clearly idiots, we're writing a program in Go. Pointing out how Rust would do it better isn't helping.
Fitting analogy: If there's an article about McDonald's, people would always talk about Wendy's instead. No one would mention BurgerKing (C++), Subway (D), KFC, ...
PHP must be Taco Bell. It solves a lot of problems quickly, but you'll pay for it later.
I chose my analogy carefully. Coca-Cola tried to change its recipe to make it sweeter because they did studies and found people liked the taste of Pepsi more. So any discussion of changing Coke's flavor means Pepsi is highly relevant. But the converse is not necessarily true. Pepsi doesn't have any (recent) history of trying to match their flavor to Coke.
Maybe a better analogy is this: if Mercedes comes out with an electric car, you should expect to see Tesla in the discussions. But if Tesla comes out with a combustion engine, there's nothing particularly relevant about Mercedes in that discussion.
I'm sure that if there were discussions about adding structural typing or lightweight fibers to Rust, then Go would show up. But most of the discussions tend to be around adding generics or sum types to Go.
I’ve been a long-time user of Haskell, but I can safely say Rust has supplanted it almost entirely for me at this point. I never would have felt comfortable betting on Haskell in a commercial environment. Rust? Absolutely.
If any of these features is of significant value to a programming use case, it is worth talking about rust:
* Speed
* Type safety
* Memory safety
* Memory determinism
* Latency
* RAII-based resource acquisition and destruction
* Concurrency correctness / safety
* Minimal runtime requirements
* Low level bit manipulation (eg. Cryptography, compression)
* Startup time
* Networking
This isn't exhaustive, but it gives a lot of different people in different domains working on different problems a reason to talk about the same language when comparing to their usual choices.
That is context for discussion, and yes, it is relevant. Directly relevant, in fact.
I wanted to hear what Go devs have to say about this latest iteration of the generics proposal. But to do that I have to wade through endless comments about type systems and Rust. Even on comments directly talking about this iteration and how to use it, every other reply starts with "In Rust..."
If implementing generics leads more of the Rust community back to Go, then from what I've seen here: no thanks. I have a feeling we'd see every conversation in every community forum start with "In Rust.."
It's also a great discussion for the go community to have. The only problem here is that it's not a discussion you wanted to have. Should every discussion about go revolve around you and your wants?
If all you wanted was to hear what the go devs wanted to say, you could have clicked on the link and read it. Or could you possibly use the feature that was built for you: the [-] button to collapse a thread. Or maybe, just maybe, you could go to a place that is explicitly only about go, like /r/golang.
But it's every freaking time. Every single time Go is mentioned, there's a ton of Rust folk commenting on how Rust does it (better).
Just for once, it'd be nice to have a comment thread discussing a Go-specific item, that has nothing to do with Rust, without talking about Rust.
And yeah, /r/golang is at least Go-focused. But it has its own problems too. Mostly PHP and JS folks learning Go and asking basic questions (which would be great if they didn't then reply to the answers with "but that's not how PHP/JS does it, why does Go do it so strangely?" and without reading any of the billion answers for that question already).
Sorry if my exasperation is showing ;)
The only cases I know of are people moved to Rust to avoid GC pauses.
To me, Go vs JVM ecosystem languages is a much more difficult choice. I would have to actually think a bit.
To me, Rust and Go really don't occupy the same ecosystem niche. I can't think of a project where I would have to choose between them--the choice between them is almost always dead obvious given the project description.
Edit: last I looked you could see how many OS threads would be used by looking at runtime.GOMAXPROCS. There was a time when it would just default to 1, but it looks like they changed it. When I last programmed in Go you had to override it via an environment variable or set it in code.
> a style of computer programming characterized by the _ritual_ inclusion of code or program structures that serve no real purpose.