|
|
|
|
|
|
by kazagistar
3485 days ago
|
|
|
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. |
|
|
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.