4 ms·

> only after an extended period of time of independent vetting Let's face it, what will your average dev do in the absence of something being in stdlib ? They

> only after an extended period of time of independent vetting Let's face it, what will your average dev do in the absence of something being in stdlib ? They will (semi)randomly pick some third-party crate which in all likelihood is totally unvetted. The crate that they selected could equally turn stale and outdated quickly if its a small one-man-band Github party (a not unfamiliar story these days). Hence, having a standardised baseline available in stdlib is no bad thing IMHO. It brings "sane defaults" and forces anyone wanting to do different to make a thought-out decision, not just grab whatever Crate "looks good" so they can get on with coding.

the_mitsuhiko 5y ago
> They will (semi)randomly pick some third-party crate which in all likelihood is totally unvetted. That's okay though. It's better for some devs to (temporarily) pick some bad crates than to permanently include some broken legacy APIs in the standard library that need to stay there due to compatibility issues. Even Python 3 couldn't get rid of a lot of code that just should not be in the standard library.
- ericbarrett 5y ago
  I disagree quite strongly. A bad stdlib API can be deprecated; a bad crate bitrots. You won't see the situation so clearly at first, but after a few years you will find that an increasing number of useful crates no longer compile without intervention because direct or transitive dependencies no longer exist.
  - mplanchard 5y ago
    Rust commits much more strongly to backwards compatibility than a language like Python. Deprecating something in the stdlib would be a big deal. The fact is that in practice, for most “standard” functionality that isn’t in the stdlib, there are well maintained, well vetted crates written by well known authors (or even developers of the stdlib). These are not hard to find, either by asking around or looking at what other crates use. Rust’s stdlib is consistently of high quality. I can use everything in it without worry or concern. I can’t say the same about Python.
    - ericbarrett 5y ago
      Rust has already deprecated stuff in stdlib, though. It gets tagged as deprecated, and an alternative is generally provided, but the deprecated function sticks around so that stuff that uses it doesn't break. Seems like the best solution to me.
      - mplanchard 5y ago
        Yeah this is true, but to my knowledge that’s never been done since 1.0 with an entire module, just certain functions (could be wrong, but I have never seen it). Keeping deprecated functions around still requires some maintenance burden, because you can’t break them just because they’re deprecated. That maintenance burden might become pretty extreme if we’re talking about something as complicated as an HTTP server module, as some folks are asking for in this thread. I also personally don’t want to see the standard library littered with failed and deprecated experiments. In addition to the maintenance burden, it adds confusion when you’re learning the language or trying to discover how to do something.
zibzab 5y ago
> They will (semi)randomly pick some third-party crate which in all likelihood is totally unvetted. That this is the norm for a language that focuses on security is mind-boggling. Didn't we learn anything from the NPM mess?
skavi 5y ago
> The crate that they selected could equally turn stale and outdated quickly if its a small one-man-band Github party (a not unfamiliar story these days). Yes, but the crate dev likely offers no maintenance guarantees. A bad stdlib had to be maintained forever (and potentially divert new users from better options)
- tempest_ 5y ago
  It doesn't have to be. Code can be deprecated but it is often a long drawn out process.
  - hiptobecubic 5y ago
    Python has been at it for most of my career.
- bydlocoder 5y ago
  I mean, look at Java Futures and Streams API. Like, who the hell designed this crap? Didn't they have C# and Scala to rip-off? And it's stuck forever.
moonchrome 5y ago
The difference between having something in the standard library vs shipping it as a crate is evolution not vetting, you can have the same people develop/vet a third party crate the same as it would be if it was a part of the standard library. The big difference is versioning (eg. you can have a crate that works on old compilers/stdlib, you can pull an older package version to new compiler/stdlib) and maintenance burden.
berkes 5y ago
I disagree here. Coming from Ruby, there are lessons to be learned. Ruby has a large stdlib, like you seem to want. But a lot of stuff in there is outdated. So much, that many, even most, people, projects, frameworks immediately replace them with a community version. Sometimes because they are actually better maintained, more stable, faster, cleaner and more secure than the ones in stdlib. A similar thing is seen in Ruby-on-Rails, which adds features and even entire frameworks with every release, but which many people swap out for their own preferred lib almost immediately. This is inevitable and obvious. And, IMO should be embraced: deprecate them from stdlib, and leave it to "the community". > They will (semi)randomly pick some third-party Again good lessons can be learned from Ruby (gems) here. People will pick a "random" one only if there are no canonical, defacto-standard libs (gems) out there. But for some gems there is a clear, singular goto option and everyong will pick that, turning it into something of a stdlib. A good next step would, IMO, NOT be to then pull those libs into the stdlib, but, instead, to make the "not-fully-stdlib-but-also-not-random-community-provided" into a distinct category of libs.
- dragonwriter 5y ago
  > Coming from Ruby, there are lessons to be learned. Ruby has a large stdlib And is very aggressively moving stuff out of stdlib to three concentric circles of gems; “default gems” which are almost like stdlibs (and still tied somewhat to Ruby versions) but are separately maintained and can be updated between Ruby versions, “bundled” gems that are usually distributed with Ruby, and just plain regular gems.
  - berkes 5y ago
    Indeed. And this is one of those "lessons learned".
- bydlocoder 5y ago
  Ruby standard library is such a mess. It had like two YAML serializers at some point, right? dbm and gdbm (whatever they are)? Multiple prime number generators? Rinda (what the hell is this)? RSS? Xmlrpc? So, they had time to put in all that crap while failing to design a usable HTTP client.
afavour 5y ago
> They will (semi)randomly pick some third-party crate which in all likelihood is totally unvetted. It doesn't have to be that way, though. Why can't there be first-party crates? If the Rust core team is adding functionality to stdlib why can't they add functionality to a crate instead? Then you'd have a collection of first-party, vetted crates for devs to choose from.

the_mitsuhiko 5y ago

> They will (semi)randomly pick some third-party crate which in all likelihood is totally unvetted. That's okay though. It's better for some devs to (temporarily) pick some bad crates than to permanently include some broken legacy APIs in the standard library that need to stay there due to compatibility issues. Even Python 3 couldn't get rid of a lot of code that just should not be in the standard library.

ericbarrett 5y ago
I disagree quite strongly. A bad stdlib API can be deprecated; a bad crate bitrots. You won't see the situation so clearly at first, but after a few years you will find that an increasing number of useful crates no longer compile without intervention because direct or transitive dependencies no longer exist.
- mplanchard 5y ago
  Rust commits much more strongly to backwards compatibility than a language like Python. Deprecating something in the stdlib would be a big deal. The fact is that in practice, for most “standard” functionality that isn’t in the stdlib, there are well maintained, well vetted crates written by well known authors (or even developers of the stdlib). These are not hard to find, either by asking around or looking at what other crates use. Rust’s stdlib is consistently of high quality. I can use everything in it without worry or concern. I can’t say the same about Python.
  - ericbarrett 5y ago
    Rust has already deprecated stuff in stdlib, though. It gets tagged as deprecated, and an alternative is generally provided, but the deprecated function sticks around so that stuff that uses it doesn't break. Seems like the best solution to me.
    - mplanchard 5y ago
      Yeah this is true, but to my knowledge that’s never been done since 1.0 with an entire module, just certain functions (could be wrong, but I have never seen it). Keeping deprecated functions around still requires some maintenance burden, because you can’t break them just because they’re deprecated. That maintenance burden might become pretty extreme if we’re talking about something as complicated as an HTTP server module, as some folks are asking for in this thread. I also personally don’t want to see the standard library littered with failed and deprecated experiments. In addition to the maintenance burden, it adds confusion when you’re learning the language or trying to discover how to do something.

zibzab 5y ago

> They will (semi)randomly pick some third-party crate which in all likelihood is totally unvetted. That this is the norm for a language that focuses on security is mind-boggling. Didn't we learn anything from the NPM mess?

skavi 5y ago

> The crate that they selected could equally turn stale and outdated quickly if its a small one-man-band Github party (a not unfamiliar story these days). Yes, but the crate dev likely offers no maintenance guarantees. A bad stdlib had to be maintained forever (and potentially divert new users from better options)

tempest_ 5y ago
It doesn't have to be. Code can be deprecated but it is often a long drawn out process.
- hiptobecubic 5y ago
  Python has been at it for most of my career.
bydlocoder 5y ago
I mean, look at Java Futures and Streams API. Like, who the hell designed this crap? Didn't they have C# and Scala to rip-off? And it's stuck forever.

moonchrome 5y ago

The difference between having something in the standard library vs shipping it as a crate is evolution not vetting, you can have the same people develop/vet a third party crate the same as it would be if it was a part of the standard library. The big difference is versioning (eg. you can have a crate that works on old compilers/stdlib, you can pull an older package version to new compiler/stdlib) and maintenance burden.

berkes 5y ago

I disagree here. Coming from Ruby, there are lessons to be learned. Ruby has a large stdlib, like you seem to want. But a lot of stuff in there is outdated. So much, that many, even most, people, projects, frameworks immediately replace them with a community version. Sometimes because they are actually better maintained, more stable, faster, cleaner and more secure than the ones in stdlib. A similar thing is seen in Ruby-on-Rails, which adds features and even entire frameworks with every release, but which many people swap out for their own preferred lib almost immediately. This is inevitable and obvious. And, IMO should be embraced: deprecate them from stdlib, and leave it to "the community". > They will (semi)randomly pick some third-party Again good lessons can be learned from Ruby (gems) here. People will pick a "random" one only if there are no canonical, defacto-standard libs (gems) out there. But for some gems there is a clear, singular goto option and everyong will pick that, turning it into something of a stdlib. A good next step would, IMO, NOT be to then pull those libs into the stdlib, but, instead, to make the "not-fully-stdlib-but-also-not-random-community-provided" into a distinct category of libs.

dragonwriter 5y ago
> Coming from Ruby, there are lessons to be learned. Ruby has a large stdlib And is very aggressively moving stuff out of stdlib to three concentric circles of gems; “default gems” which are almost like stdlibs (and still tied somewhat to Ruby versions) but are separately maintained and can be updated between Ruby versions, “bundled” gems that are usually distributed with Ruby, and just plain regular gems.
- berkes 5y ago
  Indeed. And this is one of those "lessons learned".
bydlocoder 5y ago
Ruby standard library is such a mess. It had like two YAML serializers at some point, right? dbm and gdbm (whatever they are)? Multiple prime number generators? Rinda (what the hell is this)? RSS? Xmlrpc? So, they had time to put in all that crap while failing to design a usable HTTP client.

afavour 5y ago

> They will (semi)randomly pick some third-party crate which in all likelihood is totally unvetted. It doesn't have to be that way, though. Why can't there be first-party crates? If the Rust core team is adding functionality to stdlib why can't they add functionality to a crate instead? Then you'd have a collection of first-party, vetted crates for devs to choose from.