5 ms·

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.

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.