5 ms·

> My other big beef with Rust is its lack of a comprehensive stdlib, unlike Go. I think many of us are feeling these days that the rust standard library might

> My other big beef with Rust is its lack of a comprehensive stdlib, unlike Go. I think many of us are feeling these days that the rust standard library might already be too large and it's better to be very conservative adding stuff there or only after an extended period of time of independent vetting. I have yet to not experience that standard libraries turn into very stale and outdated things relatively quickly that carries an enormous maintenance burden.

flippinburgers 5y ago
Golangs stdlib is very nice to work with.
- the_mitsuhiko 5y ago
  I don't disagree, and so was Python's standard library in 2003. The issue with standard libraries is that the moment they move past algorithms, data structures and basic IO they are often not lasting for more than 5 years. Even the Go standard library is quickly aging as contexts were not around when it was first created. It will be interesting to see how Go's standard library is going to evolve with Generics and more reliance on contexts.
  - zibzab 5y ago
    > Even the Go standard library is quickly aging If anything, I found go stdlib to age like fine wine. It doesn't do everything under the sun, but what it does it does very well and can easily be extended if needed.
    - yjftsjthsd-h 5y ago
      I think the argument was that Go is still too young to make that argument in the long view.
      - tptacek 5y ago
        Well, the time threshold given above was 5 years. It's been 10 since 1.0.
  - wheelerof4te 5y ago
    Python, the language, is easy to learn. It's stdlib is not. I agree that we need a serious refactoring of Python's stdlib.
    - berkes 5y ago
      > serious refactoring of Python's stdlib. My hands start to sweat at the idea of this becoming The Python 4 Debacle.
      - wheelerof4te 5y ago
        Language semantics != stdlib.
        berkes 5y ago
        It doesn't matter why a new version would be very backwards-incompatible. Whether that is language semantics (2->3) or deprecation and replacement of stdlib (3->4 ?)
- gameswithgo 5y ago
  Yes, and it makes sense for Go to have a stdlib like this, but does it make sense for Rust? You wouldn’t use Rust unless you were aiming for low level optimizations all the time, making one size fits all standard libraries less appropriate. There is no need to make Rust like Go, Go is already a great Go.
  - oleganza 5y ago
    This has nothing to do with the properties of Go/Rust as languages, but all about organizational structure. Go is supported by Google who can put necessary resources to include a bunch of high-level batteries in the stdlib and keep it coherent. Rust community does not have such resources and even if there are some big players joining the community, they don't own Rust and won't be able allocate resources for continuous support without a proper org structure that allows this to be sustainable and efficient. Philosophical reasoning like "Rust should have small stdlib" is horseshit. Ideal language has every function perfectly designed in the stdlib (kinda like PHP in 2003, lol). But to get closer to that dream you need some sustainable organization that maintains and expands that stdlib, wishes to do so and has resources to do that continuously. If it's just random 5 people doing maintenance and hacking at their spare time, that's not enough for an expanding library of diverse code. That could be enough only for keeping very core features working/improving like const generics and borrow checker.
    - the_mitsuhiko 5y ago
      > Ideal language has every function perfectly designed in the stdlib That way of thinking only makes sense if nothing ever changes. You even bring PHP as a good example here of how this fails fast. The world has changed greatly since 2003. The Python standard library carries three XML implementations and an outdated HTML parser irrelevant for the modern world. These libraries were state of the art when they were written, but it's the world around it that changed. Now one can make the argument: why was it not modernized and updated? The simple answer is that people started building code against this and now depend on it working this way. The only way would be to completely rewrite them with new APIs, remove stuff no longer needed but then you're effectively back to just using crates.io and the likes. Except it's worse now because the standard library is a monolith and does not compose.
jrimbault 5y ago
I really like this tweet[1], which is bit cheeky, but gets also at the issue that everyone "basic" needs are actually different. [1]: https://twitter.com/steveklabnik/status/1367854800193413126 https://twitter.com/steveklabnik/status/1367854800193413126
- Macha 5y ago
  To be fair, C++ has std::map and iostream/printf, so two of the examples given here as "in Rust's standard library and not in C++'s" are wrong. Now there are reasons many people choose not to use the built in C++ std::map, and very nearly this ended up the case for Rust's HashMap, until they switched the implementation to the crate that was becoming popular. But even there's design decisions, like Rust using more compute to have a strong hash to avoid DoS attacks, that some may feel are inappropriate for their use cases.
  - jcranmer 5y ago
    You probably mean std::unordered_map, not std::map. std::map is a red-black tree, so it's akin to TreeMap in Java or BTreeMap in Rust. (It really is a shame that the smallest name for an associative array in C++ is for the version that is the least useful).
traceroute66 5y ago
> 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.
benschulz 5y ago
I wish there was an `Either` type in std. I realize that there used to be one and we have `Result` now. However, now that we have `impl Trait` it's worth revisiting, I believe. If we don't we'll have the one from `itertools`, the one from `futures` etc. In most GCed languages it wouldn't matter so much because you'd return a boxed `Iterator` or `Future` or what have you. But in Rust you generally want to avoid the allocation.
- the_mitsuhiko 5y ago
  I think most people end up regretting code that users itertools::Either at the moment and use it reluctantly.
  - benschulz 5y ago
    Can you expand on that? As long as the public type is opaque I don't see what there is to regret.
    - zaarn 5y ago
      As someone with difficulties telling left and right apart, using Either isn't particularly straight forward. This plus the left and right variant become meaningless on their own. Ie, if I wanted an enum of either a string or an integer, it becomes "Either<&str, i64>". But what I wanted is that it's either a string identifier or the database Id of something to be later referenced, which might be better described as "enum IdentOrDbId { Ident(String), DbId(i64) }". This is of course a much simplified example of things I've faced.
      - benschulz 5y ago
        Sorry, based on the replies I'm getting I did not make myself clear. I only want to use Either in cases like the following. fn some_func() -> impl SomeTrait { if some_condition { Either::Left(a) } else { Either::Right(b) } } Both a and b will implement SomeTrait which is all callers care about. However, because they're structurally different they must be wrapped in an Either that delegates all methods from SomeTrait to a or b respectively.
wheelerof4te 5y ago
Oh, what will people do if there's no library for their little snowflake problem? How could you ever possibly, gasp, write it yourself? Oh the horrors of computer science. Seriously, many times I find myself needing only a fraction of some provided library.
- JabavuAdams 5y ago
  They will be unproductive. Yeah, it's fun to micro-obsess over some hand-rolled code. Save that for side projects, or maybe you can do it if you're dev cog N+1, N > 20.
  - JabavuAdams 5y ago
    I'd be interested to know the distribution of sizes of organizations that write software. What proportion of all software development orgs are < 5 devs, < 10 devs?
- berkes 5y ago
  > needing only a fraction of some provided library. In a compiled language like Rust, that should not matter, isn't it? The binary-size, performance or attack-surface should not increase from code that is unused as it won't be in the resulting binary. Or did I understand it completely wrong?
christophilus 5y ago
> I have yet to not experience that standard libraries turn into very stale and outdated things relatively quickly that carries an enormous maintenance burden Maybe. I think .NET's core libs are excellent. So are Go's. I'm sure it's a maintenance burden, but man... It's so nice to be able to build a project with maybe 1-2 dependencies instead of 100s (as in my typical Node and Ruby projects, if you count transitive dependencies). It's hard to overstate how much of a strength I think a good stdlib is.

flippinburgers 5y ago

Golangs stdlib is very nice to work with.

the_mitsuhiko 5y ago
I don't disagree, and so was Python's standard library in 2003. The issue with standard libraries is that the moment they move past algorithms, data structures and basic IO they are often not lasting for more than 5 years. Even the Go standard library is quickly aging as contexts were not around when it was first created. It will be interesting to see how Go's standard library is going to evolve with Generics and more reliance on contexts.
- zibzab 5y ago
  > Even the Go standard library is quickly aging If anything, I found go stdlib to age like fine wine. It doesn't do everything under the sun, but what it does it does very well and can easily be extended if needed.
  - yjftsjthsd-h 5y ago
    I think the argument was that Go is still too young to make that argument in the long view.
    - tptacek 5y ago
      Well, the time threshold given above was 5 years. It's been 10 since 1.0.
- wheelerof4te 5y ago
  Python, the language, is easy to learn. It's stdlib is not. I agree that we need a serious refactoring of Python's stdlib.
  - berkes 5y ago
    > serious refactoring of Python's stdlib. My hands start to sweat at the idea of this becoming The Python 4 Debacle.
    - wheelerof4te 5y ago
      Language semantics != stdlib.
      - berkes 5y ago
        It doesn't matter why a new version would be very backwards-incompatible. Whether that is language semantics (2->3) or deprecation and replacement of stdlib (3->4 ?)
gameswithgo 5y ago
Yes, and it makes sense for Go to have a stdlib like this, but does it make sense for Rust? You wouldn’t use Rust unless you were aiming for low level optimizations all the time, making one size fits all standard libraries less appropriate. There is no need to make Rust like Go, Go is already a great Go.
- oleganza 5y ago
  This has nothing to do with the properties of Go/Rust as languages, but all about organizational structure. Go is supported by Google who can put necessary resources to include a bunch of high-level batteries in the stdlib and keep it coherent. Rust community does not have such resources and even if there are some big players joining the community, they don't own Rust and won't be able allocate resources for continuous support without a proper org structure that allows this to be sustainable and efficient. Philosophical reasoning like "Rust should have small stdlib" is horseshit. Ideal language has every function perfectly designed in the stdlib (kinda like PHP in 2003, lol). But to get closer to that dream you need some sustainable organization that maintains and expands that stdlib, wishes to do so and has resources to do that continuously. If it's just random 5 people doing maintenance and hacking at their spare time, that's not enough for an expanding library of diverse code. That could be enough only for keeping very core features working/improving like const generics and borrow checker.
  - the_mitsuhiko 5y ago
    > Ideal language has every function perfectly designed in the stdlib That way of thinking only makes sense if nothing ever changes. You even bring PHP as a good example here of how this fails fast. The world has changed greatly since 2003. The Python standard library carries three XML implementations and an outdated HTML parser irrelevant for the modern world. These libraries were state of the art when they were written, but it's the world around it that changed. Now one can make the argument: why was it not modernized and updated? The simple answer is that people started building code against this and now depend on it working this way. The only way would be to completely rewrite them with new APIs, remove stuff no longer needed but then you're effectively back to just using crates.io and the likes. Except it's worse now because the standard library is a monolith and does not compose.

jrimbault 5y ago

I really like this tweet[1], which is bit cheeky, but gets also at the issue that everyone "basic" needs are actually different. [1]: https://twitter.com/steveklabnik/status/1367854800193413126 https://twitter.com/steveklabnik/status/1367854800193413126

Macha 5y ago
To be fair, C++ has std::map and iostream/printf, so two of the examples given here as "in Rust's standard library and not in C++'s" are wrong. Now there are reasons many people choose not to use the built in C++ std::map, and very nearly this ended up the case for Rust's HashMap, until they switched the implementation to the crate that was becoming popular. But even there's design decisions, like Rust using more compute to have a strong hash to avoid DoS attacks, that some may feel are inappropriate for their use cases.
- jcranmer 5y ago
  You probably mean std::unordered_map, not std::map. std::map is a red-black tree, so it's akin to TreeMap in Java or BTreeMap in Rust. (It really is a shame that the smallest name for an associative array in C++ is for the version that is the least useful).

traceroute66 5y ago

> 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.

benschulz 5y ago

I wish there was an `Either` type in std. I realize that there used to be one and we have `Result` now. However, now that we have `impl Trait` it's worth revisiting, I believe. If we don't we'll have the one from `itertools`, the one from `futures` etc. In most GCed languages it wouldn't matter so much because you'd return a boxed `Iterator` or `Future` or what have you. But in Rust you generally want to avoid the allocation.

the_mitsuhiko 5y ago
I think most people end up regretting code that users itertools::Either at the moment and use it reluctantly.
- benschulz 5y ago
  Can you expand on that? As long as the public type is opaque I don't see what there is to regret.
  - zaarn 5y ago
    As someone with difficulties telling left and right apart, using Either isn't particularly straight forward. This plus the left and right variant become meaningless on their own. Ie, if I wanted an enum of either a string or an integer, it becomes "Either<&str, i64>". But what I wanted is that it's either a string identifier or the database Id of something to be later referenced, which might be better described as "enum IdentOrDbId { Ident(String), DbId(i64) }". This is of course a much simplified example of things I've faced.
    - benschulz 5y ago
      Sorry, based on the replies I'm getting I did not make myself clear. I only want to use Either in cases like the following. fn some_func() -> impl SomeTrait { if some_condition { Either::Left(a) } else { Either::Right(b) } } Both a and b will implement SomeTrait which is all callers care about. However, because they're structurally different they must be wrapped in an Either that delegates all methods from SomeTrait to a or b respectively.

wheelerof4te 5y ago

Oh, what will people do if there's no library for their little snowflake problem? How could you ever possibly, gasp, write it yourself? Oh the horrors of computer science. Seriously, many times I find myself needing only a fraction of some provided library.

JabavuAdams 5y ago
They will be unproductive. Yeah, it's fun to micro-obsess over some hand-rolled code. Save that for side projects, or maybe you can do it if you're dev cog N+1, N > 20.
- JabavuAdams 5y ago
  I'd be interested to know the distribution of sizes of organizations that write software. What proportion of all software development orgs are < 5 devs, < 10 devs?
berkes 5y ago
> needing only a fraction of some provided library. In a compiled language like Rust, that should not matter, isn't it? The binary-size, performance or attack-surface should not increase from code that is unused as it won't be in the resulting binary. Or did I understand it completely wrong?

christophilus 5y ago

> I have yet to not experience that standard libraries turn into very stale and outdated things relatively quickly that carries an enormous maintenance burden Maybe. I think .NET's core libs are excellent. So are Go's. I'm sure it's a maintenance burden, but man... It's so nice to be able to build a project with maybe 1-2 dependencies instead of 100s (as in my typical Node and Ruby projects, if you count transitive dependencies). It's hard to overstate how much of a strength I think a good stdlib is.