5 ms·

The Rust stdlib is specifically intended to be as lightweight as possible (while still providing those idiomatic abstractions that might be needed throughout th

The Rust stdlib is specifically intended to be as lightweight as possible (while still providing those idiomatic abstractions that might be needed throughout the ecosystem, e.g. std.future) in order to avoid the Python "dead batteries" problem. What the Rust ecosystem is still lacking is a quasi-standard "Rust Platform" of best-practice library components where the community can freely deprecate something when a clearly better replacement comes along. There are a few "community" websites that try to provide guidance wrt. some parts of the Rust ecosystem, but nothing that feels even close to official or consensus-driven.

oblio 7y ago
Rust needs something like Rust dev blessed "extension packs", in my opinion. Sort of like VS Code has extension packs. Basically have some metapackages for common development areas, that pull in community vetted, high quality libraries for certain areas.
- empath75 7y ago
  why do they need to be dev blessed? You could do something like conda that's basically a distribution.
- steveklabnik 7y ago
  We have tried to suggest this, but the community has overwhelmingly rejected it, both as an explicit plan, and when people provided such a thing.
  - davemp 7y ago
    That's unfortunate. Whenever I talk about rust with my coworkers, getting crates through IT comes up as a major deal breaker. I imagine cooperate approved "packs" would make it much easier for us rust hobbyists to get some projects started at work in rust. See python: my workplace (and I'm sure many others) is stuck with what's in anaconda for better or worse. The situation is certainly better than pure std.
the_duke 7y ago
In my opionion the stdlib is a bit too conservative. It is easy to end up with 200+ dependencies on more complex projects. Some things should definitely be moved into std over the long term. BUT: the time is not now. The language is still evolving rapidly. Upcoming features like specialization and a form of higher kinded types have the potential to impact API design a lot. I also really want named function arguments. No-one wants to end up with a outdated and arcane standard library.
- cyphar 7y ago
  The main problem is that you cannot version the standard library (well, there are "editions" but that's a bit of a workaround for other language changes). Go has the exact same problem, and has also historically made similar mistakes to Rust in their stdlib (the "syscall" module is strongly recommended against -- instead you should use "golang.org/x/sys"). And it should be noted that Go is even more bare-bones than Rust -- the lack of generics means you have to use "containers" which is very limited (I also have a feeling it's used by effectively nobody, because of the bad ergonomics). I think the best solution for this problem might be some form of "meta-crate" concept which would allow you to pull in all of the well-vetted and stable libraries that most people want, without having to curate ~20 libraries yourself.
  - the_duke 7y ago
    > And it should be noted that Go is even more bare-bones than Rust In certain ways Go is more bare bones, but Go also comes with common hashes, some crypto primitives, encodings like JSON, compression/archives, logging, date/time utilities, Regex, a templating engine, an http client and server, regex, .... All of which requires a dependency with Rust. I do remember an effort of a meta package like you mentioned. I think it was driven by brson and on Github, but I can't find it now, and it was abandoned anyway.
    - cyphar 7y ago
      The problem is that several of those standard library components are no longer recommended for general usage: * As with "syscall", users are strongly suggested to use "golang.org/x/crypto" for crypto primitives like AEAD. All of the crypto bits in the standard library are probably still "okay" but there are better interfaces and more efficient implementations in "golang.org/x/crypto". * The "flags" package is basically useless for large projects (everyone uses "cobra" or "spf13/cli" to create CLI interfaces now). It also has the really weird Go-ism of "-flag" arguments. * For logging, most people use "logrus" or similar. "log" isn't necessarily bad, but it's not full-featured enough that most people end up not using it. * As for HTTP servers, at the very least you'll use "gorilla" to deal with routes -- if not completely switch to a different HTTP server implementation. * Not to mention some of the other weird bits and bobs which are useful, but are strange to include in such a small stdlib, like "mime". Or some of the more fruity stuff like "database". This is the downside of the batteries-included model. Especially when a lot of the bits in the Go stdlib were included early in the language's life and then quickly became a clearly bad idea but it was too late to remove them.
xiphias2 7y ago
When I search for the Python dead batteries problem, the main issue is that the Rust developers don't want to maintain a growing list of libraries forever, especially that some of them will be depreciated over time. This is totally understandable position, but it is still important to have sensible defaults for common tasks for end users. One example that I can point to is Haskell, which I tried to learn from Haskell books, and it took me years to realize that it's not the language that's extremely inefficient, but the default libraries that use lists instead of arrays for most of the tasks. I'm writing about Rayon because I see it as a reoccuring discoverability problem for people who are new to Rust. There are many possible solutions, but one would be to have a default list of dependencies created in Cargo.toml that can of course be modified by the Rust users. Also that list can of course be changed over time by Rust developers.

oblio 7y ago

Rust needs something like Rust dev blessed "extension packs", in my opinion. Sort of like VS Code has extension packs. Basically have some metapackages for common development areas, that pull in community vetted, high quality libraries for certain areas.

empath75 7y ago
why do they need to be dev blessed? You could do something like conda that's basically a distribution.
steveklabnik 7y ago
We have tried to suggest this, but the community has overwhelmingly rejected it, both as an explicit plan, and when people provided such a thing.
- davemp 7y ago
  That's unfortunate. Whenever I talk about rust with my coworkers, getting crates through IT comes up as a major deal breaker. I imagine cooperate approved "packs" would make it much easier for us rust hobbyists to get some projects started at work in rust. See python: my workplace (and I'm sure many others) is stuck with what's in anaconda for better or worse. The situation is certainly better than pure std.

the_duke 7y ago

In my opionion the stdlib is a bit too conservative. It is easy to end up with 200+ dependencies on more complex projects. Some things should definitely be moved into std over the long term. BUT: the time is not now. The language is still evolving rapidly. Upcoming features like specialization and a form of higher kinded types have the potential to impact API design a lot. I also really want named function arguments. No-one wants to end up with a outdated and arcane standard library.

cyphar 7y ago
The main problem is that you cannot version the standard library (well, there are "editions" but that's a bit of a workaround for other language changes). Go has the exact same problem, and has also historically made similar mistakes to Rust in their stdlib (the "syscall" module is strongly recommended against -- instead you should use "golang.org/x/sys"). And it should be noted that Go is even more bare-bones than Rust -- the lack of generics means you have to use "containers" which is very limited (I also have a feeling it's used by effectively nobody, because of the bad ergonomics). I think the best solution for this problem might be some form of "meta-crate" concept which would allow you to pull in all of the well-vetted and stable libraries that most people want, without having to curate ~20 libraries yourself.
- the_duke 7y ago
  > And it should be noted that Go is even more bare-bones than Rust In certain ways Go is more bare bones, but Go also comes with common hashes, some crypto primitives, encodings like JSON, compression/archives, logging, date/time utilities, Regex, a templating engine, an http client and server, regex, .... All of which requires a dependency with Rust. I do remember an effort of a meta package like you mentioned. I think it was driven by brson and on Github, but I can't find it now, and it was abandoned anyway.
  - cyphar 7y ago
    The problem is that several of those standard library components are no longer recommended for general usage: * As with "syscall", users are strongly suggested to use "golang.org/x/crypto" for crypto primitives like AEAD. All of the crypto bits in the standard library are probably still "okay" but there are better interfaces and more efficient implementations in "golang.org/x/crypto". * The "flags" package is basically useless for large projects (everyone uses "cobra" or "spf13/cli" to create CLI interfaces now). It also has the really weird Go-ism of "-flag" arguments. * For logging, most people use "logrus" or similar. "log" isn't necessarily bad, but it's not full-featured enough that most people end up not using it. * As for HTTP servers, at the very least you'll use "gorilla" to deal with routes -- if not completely switch to a different HTTP server implementation. * Not to mention some of the other weird bits and bobs which are useful, but are strange to include in such a small stdlib, like "mime". Or some of the more fruity stuff like "database". This is the downside of the batteries-included model. Especially when a lot of the bits in the Go stdlib were included early in the language's life and then quickly became a clearly bad idea but it was too late to remove them.

xiphias2 7y ago

When I search for the Python dead batteries problem, the main issue is that the Rust developers don't want to maintain a growing list of libraries forever, especially that some of them will be depreciated over time. This is totally understandable position, but it is still important to have sensible defaults for common tasks for end users. One example that I can point to is Haskell, which I tried to learn from Haskell books, and it took me years to realize that it's not the language that's extremely inefficient, but the default libraries that use lists instead of arrays for most of the tasks. I'm writing about Rayon because I see it as a reoccuring discoverability problem for people who are new to Rust. There are many possible solutions, but one would be to have a default list of dependencies created in Cargo.toml that can of course be modified by the Rust users. Also that list can of course be changed over time by Rust developers.