3 ms·

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.
  - binarycrusader 12y ago
    Sorry; I'll have to disagree. As part of a group that maintains Python packages for an operating system distribution, my experience has generally been more positive for the standard library compared to third-party components. Particularly when it comes to security issues.
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.

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.
- binarycrusader 12y ago
  Sorry; I'll have to disagree. As part of a group that maintains Python packages for an operating system distribution, my experience has generally been more positive for the standard library compared to third-party components. Particularly when it comes to security issues.

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.