Rust has a sizable and well featured standard library at this point. I think it would be absurd to claim that the base language is "near-unusable" if you are using it for system programming, which is its intended use case.
Huge standard libraries make sense for Java, Go, Apple platform etc. because they are developed by giant enterprises that can manage the overhead. Thinner modular systems are a more natural fit for open source development.
Thinner modular systems also require some good tooling and a good platform that ensures many security properties.
You will be trading a stable and vetted huge standard library for 200 small packages that may all be targets for supply-chain attack. Open-source projects don't all have the resources unfortunately to keep track of all their dependencies, so I'm not sure it's necessarily a more natural fit.
True. And the rust standard library is pretty good. But I really wish we had a good, fast, small futures executor in std. And accompanying async variants of File and Socket and so on.
Async rust is a jungle of weird compatibility questions. People treat async runtimes like sports teams. (I know I do). I wish it were more like Nodejs where async is just built in.
While admittedly async is a bit of a jungle for newcomers, I am glad that it is not built into the standard library. Where you see a bunch of needlessly competing runtimes, I see a healthy variety of different packages tailored to different users and technical specializations: tokio - reasonable default and server applications; smol - desktop applications or those who prefer the simplicity; embassy - embedded applications; futures crate - runtime agnostic utilities. I will gladly reach for any one of these depending on the kind of application I am developing.
Serde is not even part of the standard library. There’s no HTTP client (let alone server), logging, decent date/time…
That’s not what I call well featured.
Most programs should need close to zero dependencies.
Of course they’re free to do what they want, and there’s the question of maintenance overhead[0], but while https://blessed.rs/ needs to exist, Rust’s standard library is deficient in my eyes.
[0] One idea would be to treat a language more like an Linux distro and have library maintainers like package maintainers but a unified quality, audit, and release process
It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality.
While overhead is a real concern, I think it’s often blown out of proportion. Once a language achieves a certain baseline of stability and isn’t in constant flux and the standard library matures, changes become infrequent and maintenance load is low. The work is heavily front-loaded.
Not at all true, look at the large parts of Python's standard library that are effectively unusable or irrelevant. And they even allow some breaking changes over time (unlike Rust). This is especially true when it comes to anything related to internet protocols or file formats, but there are other modules that have far better replacements on PyPi too (re vs regex for example).
> It’s being used for a wide variety of other purposes however, and so perhaps it’s time to adapt to that reality.
Who is going to pay for the resources to make that happen, though? The reality is that the bulk of Rust contributions come from a fairly small group of people, many of whom are volunteers. Some are Mozilla employees, and they don't have all the funding in the world.
Yes, it would be great if every open source project could magically be able to meet the needs of all its users, but that just isn't how it works.
Huge standard libraries make sense for Java, Go, Apple platform etc. because they are developed by giant enterprises that can manage the overhead. Thinner modular systems are a more natural fit for open source development.