[StevePerkins]

Are there really a lot of "shared use cases" between Rust and Go?

I realize that Go's creators intended for it to be a systems language. In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world. Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency.

Of course they're both general-purpose languages in theory. But in the real world, one is really competing with Java and Python while the other is competing with C++. I don't even see Go and Rust as head-to-head competitors at all... and I definitely don't understand their uni-directional "feud" (i.e. nearly every Rust thread is has people taking shots at Go, yet most Go threads don't mention Rust at all).

[kazagistar]

It's a unidirectional feud because Rust isn't limiting itself to C++ use cases. As the Async and other library infrastructure falls into place, why not use Rust for webapps, microservices, and command line tools? Just because it is suited for 0-overhead, high safety, with high level abstractions does not mean it's unsuited for these other things; or at least we don't know yet exactly.

On the other hand, Go is aware of its limitations, and thus has no need to fire any shots back, so to speak.

[StevePerkins]

It will be interesting to see if Rust can prove competitive in the webapp/microservice space over time.

However, the standard library and surrounding ecosystem for all the other players "fell into place" years ago. Java and Python have robust and well-maintained (sorry Node!) libraries and drivers for everything you could imagine. The biggest draw for Go is probably that its standard library is so complete, you seldom need many outside dependencies at all. Other rising stars such as Elixir are basically web-first from the start, rather than hoping to grow into it later.

From what little tinkering I've done with Rust... it seems to have a much steeper learning curve than other languages, and an ecosystem with few database drivers and only a couple of half-baked web frameworks (http://www.arewewebyet.org). I don't mean that disrespectfully, since it clearly has generated a lot of excitement in other niches.

However, I personally don't really care about those other niches. We web folks are a much larger community, and for the most part we don't really care whether or not a language uses garbage collection (web apps are more likely to be I/O-bound rather than CPU-bound). So while I would love for Rust to become another serious option, it's basically optimized in the wrong direction for the web mass market... and lags years behind in the ecosystem support that they care more about.

[steveklabnik]

I (and the rest of the team) don't really see it as a feud at all. There's always room for more languages, and we're fundamentally pluralists. There is no reason at all that Rust and Go can't or shouldn't coexist just fine.

[dispose13432]

>Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency.

Why can't Firefox tolerate garbage collection latency?

[steveklabnik]

Rendering webpages is a very intense task. Many of the improvements Servo is working on are basically "how can we transpose AAA video game technologies and techniques into web page rendering." The problems are more similar than you'd imagine.

[rat87]

> In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world.

I don't know about microservices but I think it could compete for command-line devops apps.

[sixbrx]

> "nearly every Rust thread is has people taking shots at Go"

Often resulting from "this is so much more complicated than Go, why bother?" prodding as seen in lukaslalinsky's post above, at which point those "shots" are just asked-for information.