> Its limited compared to Go as well.

It depends on perspective. Go is tailored for writing backends, so it's great that it provides things like net/http (we could also interpret cause and effect inversely here; Go provides net/http so it gets used for writing backends). Rust's standard library is actually pretty damn huge, but it doesn't index heavily into specific applications, and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it. Rust's stdlib is "small" if all you want to do is build a webserver and don't want to go shopping around for libraries, but anyone who's intimately familiar with Rust's stdlib can tell you for a fact that it's absolutely not small in absolute terms. Rust literally stabilizes hundreds of new stdlib functions per year.

▲

traceroute66 2 hours ago | parent [-]

> and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it

So in other words Rust forces you to either (a) re-invent the wheel (yet again !) or (b) import yet-another-crate into your project.

Of course if you choose (b), then its having first wasted your time deciding which of hundreds of yet-another-crate-doing-the-same-thing you want to import.

Its a waste of time and effort for the majority of projects where you are not working with embedded systems or trying to squeeze every micro-second of performance out of your system.

Sadly the majority of Rust projects show exactly zero import discipline, both from a pure import perspective and a security perspective. Which is why many Rust projects end up importing a gazillion crates.

Import discipline in Rust is hard work. Sure you can reach "reasonably necessary" level of imports the majority of Rust projects simply don't bother because its such a pain in the backside.

Don't get me wrong, Rust has its place in this world. But for many people on many projects they would be better off using Go and only using Rust where there is actually a serious use-case for it in their environment.

	▲	kibwen 28 minutes ago \| parent [-]
		> Rust forces you to either (a) re-invent the wheel (yet again !) This is inherent to the domain of systems programming. One-size-fits-all solutions only suffice until you need extreme performance. So, for example, Rust provides a basic hashmap in the stdlib, and as a generalist hashmap it's quite close to state-of-the-art. But as a generalist hashmap it's also beaten in specific applications by specialist datastructures, and Rust needs to provide support for building those specialist datastructures in a way that makes them feel just as first-class as what the stdlib provides. Go gets away with what it does because it's for domains where it's acceptable to trade uniformity for performance. This is not a bad thing! Go is quite performant. But Rust ultimately isn't competing with Go, it's competing with C. And note that I say all this as someone who is, in fact, a stdlib maximalist. But I also say all this as someone who is conscientious and informed of the realities of what it takes to design and maintain a secure, high-performance stdlib.