4 ms·

I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? But would agree that the

I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? But would agree that the only thing Rust might need are officially supported crates, while keeping the language itself fully separate. The language is then completely free of the hastles of maintaining a stdlib that probably isn't used by most people anyway. But at the same time officially supported packages give developers and newbs a place to start, and the community some confidence that libx will be maintained in the future. I really think this solution is the best for seperation of concerns and maximizing developer productivity and efforts.

vruiz 12y ago
> Give me an example of any ecosystem where the standard library is the defacto best solution? In Go that's certainly the case and in my experience it's a great thing, only time will tell if it will end up suffering stagnation like maybe happened to python.
- oblio 12y ago
  Or what happened to Java. And probably other ecosystems. IMO a "softer", "recommended" packages approach is better longer term.
  - nostrademons 12y ago
    Ironic that you've both picked languages that are used quite effectively, if unsexily, to solve problems. Both Python and Java are at the "plateau of productivity" - there's not a whole lot of innovation going on, but they're stable, robust, and have a large ecosystem of tools that let you get work done quickly. A good portion of this is because of the stability of a large standard library that everyone can depend upon.
norswap 12y ago
For things that the standard library can do, it is usually the best choice. It's code that's already sitting on the user's machine, why use something else? And also, those are generally relatively straightforward things whose design are hard to get wrong (but there are exception, e.g. Python's urllib). Being a standard library and not a standard framework helps. For what it's worth, I use Java's standard library whenever possible. It's quite extensive and the fact that the documentation is top-notch makes it a joy to use. That being said, there are still a lot of supplemental things you might want to do, which is what things like Google Guava or Apache Commons are for. But they are to supplement, not replace the standard library. By the way, some parts of Apache Commons would be a good example of how not to design a standard library, I don't want to piece 10 objects together to do a simple utility function call.
rcxdude 12y ago
>Give me an example of any ecosystem where the standard library is the defacto best solution? Almost all of them? Unless the stdlib is utterly utterly terrible the cost of the extra dependency is not worth the difference in quality between the stdlib and library which does the same thing.
coldtea 12y ago
>I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? Python, Go, C++'s STL, Java SDK, to name a few. They might not be 100% perfect, but they are good and reliable, and always there for you. Hunting the latest "best" library that gets abandoned after a year (like in Javascript and Ruby often happens, and also Go too) gets old quickly. Of course there could be a compromise approach, as you say. A mininal standard lib for Rust PLUS a "blessed" set of Cargo packages that represent the batteries (Haskell "Platform" is like that, IIRC).
- isaacaggrey 12y ago
  > Java SDK Hardly. See Joda Time (it only took 10 years for java.time to catch up) and Apache Commons (the situation is much better now, but who hasn't turned to Apache Commons due to shortcomings in Java's standard library?). In any case, I definitely agree with the frustrations of trying to find libraries for Ruby.
  - coldtea 12y ago
    Again, people have seem to miss the point I was making. I wrote that those batteries "might not be 100% perfect" -- and as a Java programmer back in the '00s, I know the specific problem points with Java time that Joda tried to solve (btw, it has inspired the time lib in the latest SDKs IIRC). The thing is, the JDK APIs, with all their issues have been a genuine force in Java adoption, and something every Java programmer relies on. Of course there'll be some pain points, but it's nothing like having to hunt for a Collections or DB abstraction or String manipulation or XML etc lib each and every time you start a project. Having an official batteries API doesn't preclude you from using external libs (like Joda) when they are better -- whereas not having one is a genuine loss. If I have turned to Apache Commons that was overwhelmingly for things MISSING from the SDK, not for things the SDK already did. And don't get me started on the Commons code quality, with BS reinventions of the wheel, lame FactoryFactoryProxyFactorySingletonFlyweightFacades and the like, and code that was blisfully ignorant of enconding issues...
- ayrx 12y ago
mandor 12y ago
"Best" always depends on your criteria. Very often, the standard library is a "good but not best" solution from a pure performance or features point of view. However, it often wins for ease of deployment (nothing to install), ease of maintenance (the project is not likely to be abandoned), documentation, and standardization. IMHO, C++ in an example where the standard library (and its laboratory, boost) is often a very good solution for the few things it covers. It's standardized, well-documented, and not that bad from a performance point of view (of course, it's not perfect). In addition, you expect your newly hired developers to know the standard library, but not every small libraries from github...

vruiz 12y ago

> Give me an example of any ecosystem where the standard library is the defacto best solution? In Go that's certainly the case and in my experience it's a great thing, only time will tell if it will end up suffering stagnation like maybe happened to python.

oblio 12y ago
Or what happened to Java. And probably other ecosystems. IMO a "softer", "recommended" packages approach is better longer term.
- nostrademons 12y ago
  Ironic that you've both picked languages that are used quite effectively, if unsexily, to solve problems. Both Python and Java are at the "plateau of productivity" - there's not a whole lot of innovation going on, but they're stable, robust, and have a large ecosystem of tools that let you get work done quickly. A good portion of this is because of the stability of a large standard library that everyone can depend upon.

norswap 12y ago

For things that the standard library can do, it is usually the best choice. It's code that's already sitting on the user's machine, why use something else? And also, those are generally relatively straightforward things whose design are hard to get wrong (but there are exception, e.g. Python's urllib). Being a standard library and not a standard framework helps. For what it's worth, I use Java's standard library whenever possible. It's quite extensive and the fact that the documentation is top-notch makes it a joy to use. That being said, there are still a lot of supplemental things you might want to do, which is what things like Google Guava or Apache Commons are for. But they are to supplement, not replace the standard library. By the way, some parts of Apache Commons would be a good example of how not to design a standard library, I don't want to piece 10 objects together to do a simple utility function call.

rcxdude 12y ago

>Give me an example of any ecosystem where the standard library is the defacto best solution? Almost all of them? Unless the stdlib is utterly utterly terrible the cost of the extra dependency is not worth the difference in quality between the stdlib and library which does the same thing.

coldtea 12y ago

>I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? Python, Go, C++'s STL, Java SDK, to name a few. They might not be 100% perfect, but they are good and reliable, and always there for you. Hunting the latest "best" library that gets abandoned after a year (like in Javascript and Ruby often happens, and also Go too) gets old quickly. Of course there could be a compromise approach, as you say. A mininal standard lib for Rust PLUS a "blessed" set of Cargo packages that represent the batteries (Haskell "Platform" is like that, IIRC).

isaacaggrey 12y ago
> Java SDK Hardly. See Joda Time (it only took 10 years for java.time to catch up) and Apache Commons (the situation is much better now, but who hasn't turned to Apache Commons due to shortcomings in Java's standard library?). In any case, I definitely agree with the frustrations of trying to find libraries for Ruby.
- coldtea 12y ago
  Again, people have seem to miss the point I was making. I wrote that those batteries "might not be 100% perfect" -- and as a Java programmer back in the '00s, I know the specific problem points with Java time that Joda tried to solve (btw, it has inspired the time lib in the latest SDKs IIRC). The thing is, the JDK APIs, with all their issues have been a genuine force in Java adoption, and something every Java programmer relies on. Of course there'll be some pain points, but it's nothing like having to hunt for a Collections or DB abstraction or String manipulation or XML etc lib each and every time you start a project. Having an official batteries API doesn't preclude you from using external libs (like Joda) when they are better -- whereas not having one is a genuine loss. If I have turned to Apache Commons that was overwhelmingly for things MISSING from the SDK, not for things the SDK already did. And don't get me started on the Commons code quality, with BS reinventions of the wheel, lame FactoryFactoryProxyFactorySingletonFlyweightFacades and the like, and code that was blisfully ignorant of enconding issues...
ayrx 12y ago

mandor 12y ago

"Best" always depends on your criteria. Very often, the standard library is a "good but not best" solution from a pure performance or features point of view. However, it often wins for ease of deployment (nothing to install), ease of maintenance (the project is not likely to be abandoned), documentation, and standardization. IMHO, C++ in an example where the standard library (and its laboratory, boost) is often a very good solution for the few things it covers. It's standardized, well-documented, and not that bad from a performance point of view (of course, it's not perfect). In addition, you expect your newly hired developers to know the standard library, but not every small libraries from github...