I think an even more problematic corollary is the desire to put nothing in the standard library, which cause the proliferation of crates that are the "standard" way of doing things but don't really have the guarantees/benefits that come with being part of "the" standard library.
I see it kind of like Go's lack of generics, in a strange way. With Go, no one was explicitly "anti-generics", it's just the core team couldn't find a design they liked, and as time went on it became sort of a meme. "Go is opposed to generics." "No, here's that blog post by Russ Cox about finding a way to implement them." Etc, etc.
Similarly, the rust core team was afraid to settle on designs for certain libraries, pointing out things like python's various standard library HTTP modules, and at least "for now" shunting a lot of functionality out into the ecosystem. When you have limited manpower, this makes sense, but I think a lot of people have since rationalized that decision as philosophically the right thing to do, not just a way of prioritizing development work.
In other words, I feel like it's a case of a smart tactical decision growing into an identity.
The saddest example I’ve come across so far is the lack of strftime, or any way to even print a clock time / date time in std. Even JavaScript has that. In a supposedly way past 1.0 language one has to rely on 0.x third party libraries to do even the most basic things.
Disclosure: only dabbled in Rust a bit, currently maintain two crates of some traction.
> I would also prefer to have bindgen in the standard library.
That's a challenging one. I'd like to have native support for C integration as well, but we'll have to balance that with the stability of the corresponding clang interfaces, and the requirement to ship extra libraries that the Rust toolchain doesn't currently ship.
Working on it, though.
> The rand and regex crates are two other examples.
rand I'd agree with, though it would need paring down to not have as many dependencies. For regex, there are multiple tradeoffs to be made; for instance, the most popular regex crate is fast and does most of what people want but doesn't have backreferences or lookahead/lookbehind assertions.
Question: is bindgen std quality yet? It seems there are still largely unsolved problems, e.g. https://github.com/rust-lang/rust-bindgen/issues/1549 which is causing hundreds of warnings in a -sys crate of mine and for which I have no recourse.
I think the issue there is that versions are arbitrary and being able to tell when a library is 1.0 is a non-decidable problem. There are lots of 0.x crates which are stable and feel feature complete, but aren't specifically versioned as 1.0.
I would actually prefer if the Rust std would not include functionality that's not essential, for example sockets don't seem essential and the standard library does not implement them in a particularly complete and well thought out manner either IMHO.
It would indeed be nice to have some sort of middle ground, where a selection of outstanding-quality crates can be officially "endorsed" by the Rust development team, but the endorsement can be withdrawn freely if something better comes along. C++ has something like this via Boost, and Haskell has their Haskell Platform, so it's not a new idea.
Actually, I am looking for more than this because I think Rust actually has a number of libraries that I think function fairly similarly to Boost. What I really want is the language committing to a library that is available without a third-party dependency, basically under a "linking exception" to be extremely close to "use however you want", supported by the people developing the language, designed alongside the language to remain ergonomic, with support that is tied to the language, … Personally, I consider this to be a very valuable feature from a programming language. Having a "pretty good" solution available "for free" is immensely value compared to having to go look online for every little thing, evaluate the landscape, audit it, ensure the licensing matches, consider whether will remain supported, and try to work around its idiosyncrasies.
I think the proposal is specifically to bless a set of crates (that may include those developed by Rust teams, but probably also others such as regex).
Being in std implies some kind of quality standard, but it also implies no backwards incompatible changes. A set of libraries blessed by a trusted group could give you the quality standard without constraining backwards compatibility.
No, they don’t. If the Rust team maintains a crate officially and they will always do so (for reasonable values of "always"), then it is part of the standard library. Otherwise, it isn’t.
It is as simple as that. When serious, important projects depend on a standard library is because they want those guarantees. Having some members of Rust work on some crates does not give anyone those guarantees.
Which is why all those crates must be in std, or declare that the standard library is a set of crates (including core, std and others).
I don’t see how that follows. Rust could easily have a (small) standard library that is guaranteed to be present everywhere and any of a number of optional libraries that are maintained by the same team that builds the compiler and the standard library.
That’s what java spent years on getting (https://www.oracle.com/corporate/features/understanding-java...), and I think that’s the way to go for any language. It prevents the standard library from bloating, yet provides quality libraries that can be trusted. It also allows some implementations to be standard without providing all the bells and whistles. That can be useful on small platforms, and allows for ‘heavier’ optional libraries (for example a SVG renderer, PDF parser, etc)
