8 ms·

> The core libraries are feature-complete for 1.0. Can someone well informed about Rust give some impressions on the standard library? It is as comprehensive a

by vruiz 12y ago

> The core libraries are feature-complete for 1.0. Can someone well informed about Rust give some impressions on the standard library? It is as comprehensive as in python or Go for example?

steveklabnik 12y ago
Core team member here. The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside. That said, the Rust team itself maintains and provides a number of packages on Crates.io ourselves. Many of these were pulled _out_ of the standard library over the past few months.
- kibwen 12y ago
  The upside to a batteries-included stdlib is, of course, that you don't have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK, and you also don't have to wonder whether whatever lib you eventually choose will be abandoned by its developer next month. At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competition and quality. But eventually (read: no less than a year or two from now) I think it will be up to the project maintainers to officially endorse certain third-party packages and commit to their maintenance. At a certain point, the advantages of a library that's well-known, well-maintained, and well-documented outweigh the disadvantages of de jure ossification.
  - steveklabnik 12y ago
    It's been my experience that the standard library is _never_ the place for the best lib to do $WHATEVER_PARTICULAR_TASK, but different folks have different preferences. We'll see how it all shakes out!
    - binarycrusader 12y ago
      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.
  - jfaucett 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? 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.
- dragonwriter 12y ago
  > The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside. With a good package management system, a batteries-included standard library could just be a set of packages where you are guaranteed that a version of each backward-compatible to the one provided at language release (in SemVer terms, a package with the same major version number as the one packaged with the language release) would be available and maintained for the maintenance life of the language version. It wouldn't have to prevent either bug-fixes to packages out-of-band with language version upgrades, or even out-of-band new major versions of packages that support the existing language versions so long as the old major version was maintained in parallel as long as the language version was.
  - steveklabnik 12y ago
    It's true that that's possible. Gotta have those libraries actually exist first, though :) We'll see if we don't end up with something like this.
  - XorNot 12y ago
    A language where the standard is "we download the packages we need" (somewhat like npm on node) feels like it has a lot less mental overhead to it because the default is "users expect to get dependencies easily", and you don't have to spend so much time trying to target older but "default" installations of things. Which with a language like Rust capable of producing static binaries, feels like a better place to be in anyway since it's a lot easier to replace 1 executable then a whole net of shared dependencies.
- stormbrew 12y ago
  I've always thought a good compromise between these approaches, and for a while it kinda looked like at least Rubinius would go to something like it in the Ruby world (but efforts to modularize the ruby stdlib seem to have fizzled somewhat), would be to have a minimal stdlib but a broader set of basically LTS versions of exceptional packages, where they are expected to have important issues backported to a stable version alongside a version of the runtime itself. This would still allow for pulling up to the bleeding edge, or simply not using, of some of those blessed packages if you choose to by specifying them in the cargo manifest, but would still provide guidance on basic useful packages. I think it'd also be easier to boot stale packages in new releases (ie. the eternal security fail that is the yaml lib in ruby's stdlib).
megaman821 12y ago
For someone that is new to Rust how do I discover where the libraries are for the things I need to do? In the past year I have needed libraries for HTTP, XML, JSON, CSV, arg parsing, image manipulation, PDF, RDBMS, a trie (and other data structures), async i/o, threads, files, ZIP, and others.
- vhbit 12y ago
  1. http://crates.io http://crates.io - central repository of rust crates (i.e. packages) 2. https://github.com/kud1ing/awesome-rust/ https://github.com/kud1ing/awesome-rust/ - manually curated list of good libraries
- killercup 12y ago
  While others mentioned http://crates.io/ http://crates.io/ you might also be interested in http://rust-ci.org/ http://rust-ci.org/ (has categories, includes build status and quite often hosted documentation).
- burntsushi 12y ago
  CSV parsing: https://github.com/BurntSushi/rust-csv https://github.com/BurntSushi/rust-csv Arg parsing: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs

by vruiz 12y ago

> The core libraries are feature-complete for 1.0. Can someone well informed about Rust give some impressions on the standard library? It is as comprehensive as in python or Go for example?

steveklabnik 12y ago

Core team member here. The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside. That said, the Rust team itself maintains and provides a number of packages on Crates.io ourselves. Many of these were pulled _out_ of the standard library over the past few months.

kibwen 12y ago
The upside to a batteries-included stdlib is, of course, that you don't have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK, and you also don't have to wonder whether whatever lib you eventually choose will be abandoned by its developer next month. At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competition and quality. But eventually (read: no less than a year or two from now) I think it will be up to the project maintainers to officially endorse certain third-party packages and commit to their maintenance. At a certain point, the advantages of a library that's well-known, well-maintained, and well-documented outweigh the disadvantages of de jure ossification.
- steveklabnik 12y ago
  It's been my experience that the standard library is _never_ the place for the best lib to do $WHATEVER_PARTICULAR_TASK, but different folks have different preferences. We'll see how it all shakes out!
  - binarycrusader 12y ago
    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.
- jfaucett 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? 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.
dragonwriter 12y ago
> The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside. With a good package management system, a batteries-included standard library could just be a set of packages where you are guaranteed that a version of each backward-compatible to the one provided at language release (in SemVer terms, a package with the same major version number as the one packaged with the language release) would be available and maintained for the maintenance life of the language version. It wouldn't have to prevent either bug-fixes to packages out-of-band with language version upgrades, or even out-of-band new major versions of packages that support the existing language versions so long as the old major version was maintained in parallel as long as the language version was.
- steveklabnik 12y ago
  It's true that that's possible. Gotta have those libraries actually exist first, though :) We'll see if we don't end up with something like this.
- XorNot 12y ago
  A language where the standard is "we download the packages we need" (somewhat like npm on node) feels like it has a lot less mental overhead to it because the default is "users expect to get dependencies easily", and you don't have to spend so much time trying to target older but "default" installations of things. Which with a language like Rust capable of producing static binaries, feels like a better place to be in anyway since it's a lot easier to replace 1 executable then a whole net of shared dependencies.
stormbrew 12y ago
I've always thought a good compromise between these approaches, and for a while it kinda looked like at least Rubinius would go to something like it in the Ruby world (but efforts to modularize the ruby stdlib seem to have fizzled somewhat), would be to have a minimal stdlib but a broader set of basically LTS versions of exceptional packages, where they are expected to have important issues backported to a stable version alongside a version of the runtime itself. This would still allow for pulling up to the bleeding edge, or simply not using, of some of those blessed packages if you choose to by specifying them in the cargo manifest, but would still provide guidance on basic useful packages. I think it'd also be easier to boot stale packages in new releases (ie. the eternal security fail that is the yaml lib in ruby's stdlib).

megaman821 12y ago

For someone that is new to Rust how do I discover where the libraries are for the things I need to do? In the past year I have needed libraries for HTTP, XML, JSON, CSV, arg parsing, image manipulation, PDF, RDBMS, a trie (and other data structures), async i/o, threads, files, ZIP, and others.

vhbit 12y ago
1. http://crates.io http://crates.io - central repository of rust crates (i.e. packages) 2. https://github.com/kud1ing/awesome-rust/ https://github.com/kud1ing/awesome-rust/ - manually curated list of good libraries
killercup 12y ago
While others mentioned http://crates.io/ http://crates.io/ you might also be interested in http://rust-ci.org/ http://rust-ci.org/ (has categories, includes build status and quite often hosted documentation).
burntsushi 12y ago
CSV parsing: https://github.com/BurntSushi/rust-csv https://github.com/BurntSushi/rust-csv Arg parsing: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs