A big part of Go's success is due to the large and useful standard lib. This kind of ecosystem feature is much more valuable than any language feature.

If the Rust guys would understand this and put an async runtime, http server and client, crypto and some more essentials in the standard lib the adoption would be much higher. Than we would have a super robust language and a super robust ecosystem. I don't think the borrow checker is the issue with Rust slow adoption in the mainstream backend business.

I can't speak for the Rust devs, but as far as I'm aware, the longterm plan is to have more stuff in std, but only once they're fairly certain they have the right design. Async/await is a good example. The Rust community explored the design space for async runtimes for several years before they felt comfortable settling on a design for the initial pieces of std.

The process is definitely frustratingly slow, but going faster has burned the Rust devs already in the past (just look at how much stuff in std::error::Error is deprecated).

The main problem isn't just that, it's that also, Rust cannot decide that a one-size-fits-all executor is the only one. Different properties are needed for different projects, and blessing any one executor cuts off all of the rest of them.

Tokio is fantastic for web services, but is inappropriate for my microcontroller.

Do you have a notification daemon for every HN comment that mentions Rust? :)

Nope, just use the search bar.

I'd say because of the standard lib Python and Go suffer less than other languages. The third party libs benefit from the standard libs as well.

Actually at my current job one of the tech leads decisions for choosing Go was exactly this.

> standard lib Python and Go suffer less than other languages

Depends on what those "other languages" are. For example. golang has nothing on the Java standard library (e.g. what does golang have to even remotely compare with `java.util.concurrent`?)

> golang is quite notorious for its dependencies pulling in tens or even hundreds of other dependencies

Plain wrong. Just stop trolling against Go.

1. The point is that you don't need as much third lib deps with Go or Python due to the huge and useful standard libs.

2. For exaclty this reason the third party dependencies don't need as much other third party dependencies.

> Just stop trolling against Go.

Please assume good faith when responding to people: https://news.ycombinator.com/newsguidelines.html