8 ms·

I think Python and Go are two examples where the standard library has very much proven invaluable. Without it, it's difficult to be confident in the portabilit

I think Python and Go are two examples where the standard library has very much proven invaluable. Without it, it's difficult to be confident in the portability of components, and it quite frankly makes the language less attractive for use. Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-and-see" approach, but at some point, I believe "blessed" components are going to be expected and strongly desired.

steveklabnik 12y ago
Totally. Rust 1.0 is about a small, excellent, stable base. You can always add stuff, but you can never take it away...
JulianWasTaken 12y ago
Python's standard library was only invaluable when its packaging situation was near-unusable. If Rust's isn't, the same thing will be true.
- kibwen 12y ago
  I think that crates.io still has a ways to go before the situation is ideal. Discoverability of libraries is the first pain point to look at. After that, I'd like to see crates.io automatically parse an uploaded package's docs (thank you, rustdoc!) and host them on the site itself.
- binarycrusader 12y ago
  I strongly disagree with that assertion; while I readily agree that some parts of the standard library are less maintained than others, as a consumer of many third-party components, I can say without a doubt that items in the core library are generally better maintained (from a security perspective) and easier to deal with. The ease of installation has nothing to do with the desire for core components. Core components generally bring certain expectations/guarantees about security, reliability, and support.
  - JulianWasTaken 12y ago
    That's just not true. Standard library components are not better maintained, not more secure, and not easier to deal with. There are too many examples to even count of each of those -- you can take a look at PEP 476 for just one recent example.
    - chc 12y ago
      You're arguing with a general observation. The fact that it's not universally true is unsurprising. If you take the average quality of third-party libraries and the average quality of libraries in the standard library, I think you will find that the standard library is generally pretty good.
      - JulianWasTaken 12y ago
        Whether it's better than the average is irrelevant, that isn't the benchmark. It needs to be better than or equal to all of the third party libraries for it to be worthwhile, otherwise, why does it exist? When you pick a library you don't pick all of them, you pick just the best one that meets the criteria you need, and the standard library can't beat the flexibility that other people will have to better meet those criteria without needing to partake in the process upstream. (It's also not true that the standard library is generally pretty good IMHO, but that will start to veer us into subjectives [which I think the comment above my original post has already done anyhow]).
        e12e 12y ago
        > When you pick a library you don't pick all of them, you pick just the best one that meets the criteria you need, and the standard library can't beat the flexibility that other people will have to better meet those criteria without needing to partake in the process upstream. So, you're using three libraries that all depend on something like urllib - and they each use the library that fits their usecase best. Now you need to debug/review/depend on updates for 6 (7 if you also use the stdlib for something) foreign codebases rather than 3 + the standard library. It's a trade-off between old/new good/best simple/complex (or complicated/complected). A standard lib that needs to maintain stability for 10+ years can never be "best" for all that time. But by being "good enough" it can often still be the best choice overall when the life cycle of a project is considered.
- giovannibajo1 12y ago
  The opposite is also true; a good package manager can avoid the stdlib to bitrot ala Python, because you can easily swap out an old module by simply repackaging as a third party dependency. On the contrary, the benefits of having a standard set of batteries, especially those upon which other might be developed, is fundamental to a sane ecosystem development. For instance, a standard framework for async I/O programming is important, because then people can write thousands of protocols that can be fully interoperable; if 2-3 different framework arises, each one can then develop its own ecosystem of protocols and libraries (not interoperable), and it's hard to think that each one would be as rich as the one in the former scenario. The same can be said for a HTTP library, a threading library, a XML/JSON marshaling library, a threading/concurrency library, and so on.
Ao7bei3s 12y ago
Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), that contain some copy/pasteable functions the authors deemed useful as comments (itertools), have documented bugs with copy/pasteable workarounds (csv). Oh, and the way they do exceptions is a mess. Oh, and don't try to read the Python standard libraries source code. It's ugly. No, standard libraries should constrain themselves to providing a good foundation for library designers. (I still like Python, and use it a lot.) (Since you mentioned Go. One thing that I love about Go is that everything interaction with the underlying OS goes through the syscall package. Also, their designer went for more minimalism. And they didn't have to worry about design mistakes they made 25 years ago. Python is old. I'm not a fan of Gos compatibility promise: it means Go 1 will rot away too. But they're in a much better starting position.)
- binarycrusader 12y ago
  While I'll readily agree that some parts of the standard library are rotten, that's not sufficient justification to say that there shouldn't be one. I should also clarify my expectations about a standard library; to me, a standard library should have all of the basics covered (interaction with the underlying system, I/O, networking, etc.) and anything that benefits from better integration with the runtime (think data types such as those found in python's collections module). If anything, I'd argue that the main problem with Python's standard library is not the library itself, but the lack of more focused curation. Note that I never said that I expect all functionality to be available in a language's standard library; for me personally, Go's standard library has roughly the right balance.
  - nostrademons 12y ago
    The other thing that really needs to be in the standard library is protocols & interfaces that will be implemented by a number of userspace libraries. Go benefits immensely from having standard io.Reader and io.Writer types and most people implementing them instead of defining their own. Similarly, most of its web frameworks use http.ResponseWriter and http.Request instead of defining their own. Python's unittest module may be a mess as a test framework, but all the major Python unittest frameworks take a unittest.TestCase, which keeps tests portable among the different systems. The worst case is exemplified by pre-STL C++, which didn't even have a string type in the stdlib. As a result, every project and library wrote their own, which meant that you basically had to choose a C++ ecosystem and develop for it rather than write libraries that are portable across multiple C++ projects.
rodgerd 12y ago
> I think Python and Go are two examples where the standard library has very much proven invaluable. C#. The amount of time I've wasted in Java programming teams while arguing over things like which of three quirky XML parsing implmentations[1] was the One To Use while the .net team powered off and built useful functionality... [1] This was a few years ago, obviously.
- zak_mc_kracken 12y ago
  So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. Quite an odd view from a software engineer. I like having as much choice as possible.
  - giovannibajo1 12y ago
    Having a standard library for a specific task doesn't forbid alternatives to be implemented and used. But it discourages them enough, which is a very good thing for consistency (especially in reading code), lowers the barrier to entry (eg: I don't have to learn how to parse json with the specific library the project I'm contributing to is using), reduces binary size (I don't link three different http libraries, mine and those chosen by my dependencies) and generically reduce the time wasted by humanity in useless duplications of efforts. When the standard sucks, well, good alternatives will appear. Also, the sad state of Python packaging is the reason why stdlib bitrotted; technically, your package manager could take care of backward compatibility: if eg at some point in the future you want to switch from a json library to a (far) better one, more in line with how idiomatic language has evolved, you just need to repackage the old one as a third party package, and make sure the packager manager brings it down for the user automatically.
  - rodgerd 12y ago
    > So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. I prefer to get things done.
- ptx 12y ago
  C# seems to be in a similar position when it comes to JSON. There's both System.Runtime.Serialization.Json and System.Web.Script.Serialization built-in plus a whole bunch of third-party libraries (e.g. Json.NET seems to be popular). I'm still not sure which one to use.

steveklabnik 12y ago

Totally. Rust 1.0 is about a small, excellent, stable base. You can always add stuff, but you can never take it away...

JulianWasTaken 12y ago

Python's standard library was only invaluable when its packaging situation was near-unusable. If Rust's isn't, the same thing will be true.

kibwen 12y ago
I think that crates.io still has a ways to go before the situation is ideal. Discoverability of libraries is the first pain point to look at. After that, I'd like to see crates.io automatically parse an uploaded package's docs (thank you, rustdoc!) and host them on the site itself.
binarycrusader 12y ago
I strongly disagree with that assertion; while I readily agree that some parts of the standard library are less maintained than others, as a consumer of many third-party components, I can say without a doubt that items in the core library are generally better maintained (from a security perspective) and easier to deal with. The ease of installation has nothing to do with the desire for core components. Core components generally bring certain expectations/guarantees about security, reliability, and support.
- JulianWasTaken 12y ago
  That's just not true. Standard library components are not better maintained, not more secure, and not easier to deal with. There are too many examples to even count of each of those -- you can take a look at PEP 476 for just one recent example.
  - chc 12y ago
    You're arguing with a general observation. The fact that it's not universally true is unsurprising. If you take the average quality of third-party libraries and the average quality of libraries in the standard library, I think you will find that the standard library is generally pretty good.
    - JulianWasTaken 12y ago
      Whether it's better than the average is irrelevant, that isn't the benchmark. It needs to be better than or equal to all of the third party libraries for it to be worthwhile, otherwise, why does it exist? When you pick a library you don't pick all of them, you pick just the best one that meets the criteria you need, and the standard library can't beat the flexibility that other people will have to better meet those criteria without needing to partake in the process upstream. (It's also not true that the standard library is generally pretty good IMHO, but that will start to veer us into subjectives [which I think the comment above my original post has already done anyhow]).
      - e12e 12y ago
        > When you pick a library you don't pick all of them, you pick just the best one that meets the criteria you need, and the standard library can't beat the flexibility that other people will have to better meet those criteria without needing to partake in the process upstream. So, you're using three libraries that all depend on something like urllib - and they each use the library that fits their usecase best. Now you need to debug/review/depend on updates for 6 (7 if you also use the stdlib for something) foreign codebases rather than 3 + the standard library. It's a trade-off between old/new good/best simple/complex (or complicated/complected). A standard lib that needs to maintain stability for 10+ years can never be "best" for all that time. But by being "good enough" it can often still be the best choice overall when the life cycle of a project is considered.
giovannibajo1 12y ago
The opposite is also true; a good package manager can avoid the stdlib to bitrot ala Python, because you can easily swap out an old module by simply repackaging as a third party dependency. On the contrary, the benefits of having a standard set of batteries, especially those upon which other might be developed, is fundamental to a sane ecosystem development. For instance, a standard framework for async I/O programming is important, because then people can write thousands of protocols that can be fully interoperable; if 2-3 different framework arises, each one can then develop its own ecosystem of protocols and libraries (not interoperable), and it's hard to think that each one would be as rich as the one in the former scenario. The same can be said for a HTTP library, a threading library, a XML/JSON marshaling library, a threading/concurrency library, and so on.

Ao7bei3s 12y ago

Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), that contain some copy/pasteable functions the authors deemed useful as comments (itertools), have documented bugs with copy/pasteable workarounds (csv). Oh, and the way they do exceptions is a mess. Oh, and don't try to read the Python standard libraries source code. It's ugly. No, standard libraries should constrain themselves to providing a good foundation for library designers. (I still like Python, and use it a lot.) (Since you mentioned Go. One thing that I love about Go is that everything interaction with the underlying OS goes through the syscall package. Also, their designer went for more minimalism. And they didn't have to worry about design mistakes they made 25 years ago. Python is old. I'm not a fan of Gos compatibility promise: it means Go 1 will rot away too. But they're in a much better starting position.)

binarycrusader 12y ago
While I'll readily agree that some parts of the standard library are rotten, that's not sufficient justification to say that there shouldn't be one. I should also clarify my expectations about a standard library; to me, a standard library should have all of the basics covered (interaction with the underlying system, I/O, networking, etc.) and anything that benefits from better integration with the runtime (think data types such as those found in python's collections module). If anything, I'd argue that the main problem with Python's standard library is not the library itself, but the lack of more focused curation. Note that I never said that I expect all functionality to be available in a language's standard library; for me personally, Go's standard library has roughly the right balance.
- nostrademons 12y ago
  The other thing that really needs to be in the standard library is protocols & interfaces that will be implemented by a number of userspace libraries. Go benefits immensely from having standard io.Reader and io.Writer types and most people implementing them instead of defining their own. Similarly, most of its web frameworks use http.ResponseWriter and http.Request instead of defining their own. Python's unittest module may be a mess as a test framework, but all the major Python unittest frameworks take a unittest.TestCase, which keeps tests portable among the different systems. The worst case is exemplified by pre-STL C++, which didn't even have a string type in the stdlib. As a result, every project and library wrote their own, which meant that you basically had to choose a C++ ecosystem and develop for it rather than write libraries that are portable across multiple C++ projects.

rodgerd 12y ago

> I think Python and Go are two examples where the standard library has very much proven invaluable. C#. The amount of time I've wasted in Java programming teams while arguing over things like which of three quirky XML parsing implmentations[1] was the One To Use while the .net team powered off and built useful functionality... [1] This was a few years ago, obviously.

zak_mc_kracken 12y ago
So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. Quite an odd view from a software engineer. I like having as much choice as possible.
- giovannibajo1 12y ago
  Having a standard library for a specific task doesn't forbid alternatives to be implemented and used. But it discourages them enough, which is a very good thing for consistency (especially in reading code), lowers the barrier to entry (eg: I don't have to learn how to parse json with the specific library the project I'm contributing to is using), reduces binary size (I don't link three different http libraries, mine and those chosen by my dependencies) and generically reduce the time wasted by humanity in useless duplications of efforts. When the standard sucks, well, good alternatives will appear. Also, the sad state of Python packaging is the reason why stdlib bitrotted; technically, your package manager could take care of backward compatibility: if eg at some point in the future you want to switch from a json library to a (far) better one, more in line with how idiomatic language has evolved, you just need to repackage the old one as a third party package, and make sure the packager manager brings it down for the user automatically.
- rodgerd 12y ago
  > So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. I prefer to get things done.
ptx 12y ago
C# seems to be in a similar position when it comes to JSON. There's both System.Runtime.Serialization.Json and System.Web.Script.Serialization built-in plus a whole bunch of third-party libraries (e.g. Json.NET seems to be popular). I'm still not sure which one to use.