6 ms·

Why "weaker guarantees across platforms"? These crates have the same guarantees about platform support. Availability across time is also similar, really.

1wd 10y ago
In most other programming languages functions in the standard library: * Are guaranteed to work correctly on all platforms where the language works. * Will always work with the latest stable release of the language. * Will be available under one single permissive license (with a single copyright holder (body) for any purposes of required notices etc.) * Will be supported (security patches, bug fixes, etc.) with backward compatibility, more or less indefinitely (with reasonable long time frames for deprecation windows and recommended transition plans etc.) * Are under no danger of being abandoned simply due to lost interest of the author. * Crucial: Will only depend on other code in the standard library. (So all these guarantees are transitive!) And anything that's not in the standard library usually implies there are no such guarantees. This is immensely more helpful and important than the comparatively trivial ease-of-installation. If the Rust team really does explicitly extend such guarantees to non-standard library crates, that should be clearly and widely communicated. So far the focus seems more on how small the standard library is. What's the advantage for the language user? I see advantages for the Rust team, and mainly I see disadvantages for the (professional) language user. Easy-to-use cargo is nice (especially for casual language users) but is nowhere close to really making up for that.
- Manishearth 10y ago
  Most of these are true for rand. It's in the nursery so it might (probably not though) be deprecated in favor of a different library, but it would continue to work because Rust is backwards compatible. https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... has some of the motivation behind this.
  - 1wd 10y ago
    Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that? It sounds more like "not mature = ready for prime time = don't use this". According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different licenses, with zero obvious guarantees.
    - steveklabnik 10y ago
      RFCs are frozen in time; regex has since moved under rust-lang, and has a pre-release for a 1.0. That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)
      - 1wd 10y ago
        My point is researching all this puts a huge burden on (serious) users that would not be there for a big standard library. Currently the Rust approach seems quite problematic, but I think this can be solved. For example by an explicit guarantee pledged by the Rust team (or a related umbrella / organization / consortium / ...) for a certain set of libraries (platform / ecosystem / 2nd tier standard library extension / stdx / nursery / ...). I think it would be important to include in this pledge: * Transitive closure rule. (No external dependencies not covered by the pledge. Possibly with certain exceptions e.g. for bindings to big known obvious third party dependencies like SQL databases or Operating Systems.) * Uniform licensing rule. (Everything must use the exact same license, with a single group name as copyright holders and for any purposes of required notices etc.) * Maintenance, backward compatibility and platform compatibility rule. (100% compatibility forever everywhere is not even necessary, but an _explicit_ rule of thumb of what reasonable time frames for deprecation windows and recommended transition plans can be expected would be nice.) Or maybe this already exists and I'm just uninformed?
        10y ago
sevensor 10y ago
It speaks to my confusion about the role of these "blessed" crates that I assumed the reason for not including them in the standard library was that they were not supported on all platforms, or that you didn't want to commit to having them in stdlib forever. If neither of these is the reason, and you intend for these crates to persist indefinitely and be available on all supported platforms, surely they belong in the standard library? For context, I'm a Python programmer by day and well used to the comforts of its expansive standard library. From that perspective, splitting your stdlib into a first-class and a second-class stdlib seems weird, and I'm trying to make sense of it.
- Manishearth 10y ago
  The idea is that these can evolve separately from the language; they are not tied to language versions. Contrast that with Python where you have the urllib urllib2 urllib3 issue; with people going and using requests anyway. There's no inherent reason to put them in the stdlib aside from "other languages do it". And yeah, folks don't want to commit to sticking them in the stdlib forever. If a better library turns up people can switch to that; without being tied to the language version. These libraries will still be maintained, but may no longer be the recommended way to do things. Being outside the stdlib gives some liquidity to the crate.
  - mook 10y ago
    The Python urllib/urllib2 issue is a feature. It means any code that uses the old (inferior) urllib continues to work, without having to update it as urllib2 starts being used within the same function so that it can be migrated. That's what promising stability means. This applies to your last paragraph as well -- I do want to be using code that folks are trusting to be the way to do things forever (well, at least for a few years). I'm not trying to learn yet another CADT language / ecosystem. Also note that both crates mentioned in this subthread (regex and rand) are at version 0.x; to a not-really-a-rust-person like me, it signals "experimental API, avoid avoid avoid". I assume that is the reason to start a concerted effort to get everything to 1.0 levels. (I'm mostly commenting because the roadmap under discussion seems to be heading towards the sort of promised stability that I want to see; so having somebody known to be rather close to rust development saying the exact opposite rather unsettles me. Sorry.)

1wd 10y ago

In most other programming languages functions in the standard library: * Are guaranteed to work correctly on all platforms where the language works. * Will always work with the latest stable release of the language. * Will be available under one single permissive license (with a single copyright holder (body) for any purposes of required notices etc.) * Will be supported (security patches, bug fixes, etc.) with backward compatibility, more or less indefinitely (with reasonable long time frames for deprecation windows and recommended transition plans etc.) * Are under no danger of being abandoned simply due to lost interest of the author. * Crucial: Will only depend on other code in the standard library. (So all these guarantees are transitive!) And anything that's not in the standard library usually implies there are no such guarantees. This is immensely more helpful and important than the comparatively trivial ease-of-installation. If the Rust team really does explicitly extend such guarantees to non-standard library crates, that should be clearly and widely communicated. So far the focus seems more on how small the standard library is. What's the advantage for the language user? I see advantages for the Rust team, and mainly I see disadvantages for the (professional) language user. Easy-to-use cargo is nice (especially for casual language users) but is nowhere close to really making up for that.

Manishearth 10y ago
Most of these are true for rand. It's in the nursery so it might (probably not though) be deprecated in favor of a different library, but it would continue to work because Rust is backwards compatible. https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... has some of the motivation behind this.
- 1wd 10y ago
  Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that? It sounds more like "not mature = ready for prime time = don't use this". According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different licenses, with zero obvious guarantees.
  - steveklabnik 10y ago
    RFCs are frozen in time; regex has since moved under rust-lang, and has a pre-release for a 1.0. That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)
    - 1wd 10y ago
      My point is researching all this puts a huge burden on (serious) users that would not be there for a big standard library. Currently the Rust approach seems quite problematic, but I think this can be solved. For example by an explicit guarantee pledged by the Rust team (or a related umbrella / organization / consortium / ...) for a certain set of libraries (platform / ecosystem / 2nd tier standard library extension / stdx / nursery / ...). I think it would be important to include in this pledge: * Transitive closure rule. (No external dependencies not covered by the pledge. Possibly with certain exceptions e.g. for bindings to big known obvious third party dependencies like SQL databases or Operating Systems.) * Uniform licensing rule. (Everything must use the exact same license, with a single group name as copyright holders and for any purposes of required notices etc.) * Maintenance, backward compatibility and platform compatibility rule. (100% compatibility forever everywhere is not even necessary, but an _explicit_ rule of thumb of what reasonable time frames for deprecation windows and recommended transition plans can be expected would be nice.) Or maybe this already exists and I'm just uninformed?
      - 10y ago

sevensor 10y ago

It speaks to my confusion about the role of these "blessed" crates that I assumed the reason for not including them in the standard library was that they were not supported on all platforms, or that you didn't want to commit to having them in stdlib forever. If neither of these is the reason, and you intend for these crates to persist indefinitely and be available on all supported platforms, surely they belong in the standard library? For context, I'm a Python programmer by day and well used to the comforts of its expansive standard library. From that perspective, splitting your stdlib into a first-class and a second-class stdlib seems weird, and I'm trying to make sense of it.

Manishearth 10y ago
The idea is that these can evolve separately from the language; they are not tied to language versions. Contrast that with Python where you have the urllib urllib2 urllib3 issue; with people going and using requests anyway. There's no inherent reason to put them in the stdlib aside from "other languages do it". And yeah, folks don't want to commit to sticking them in the stdlib forever. If a better library turns up people can switch to that; without being tied to the language version. These libraries will still be maintained, but may no longer be the recommended way to do things. Being outside the stdlib gives some liquidity to the crate.
- mook 10y ago
  The Python urllib/urllib2 issue is a feature. It means any code that uses the old (inferior) urllib continues to work, without having to update it as urllib2 starts being used within the same function so that it can be migrated. That's what promising stability means. This applies to your last paragraph as well -- I do want to be using code that folks are trusting to be the way to do things forever (well, at least for a few years). I'm not trying to learn yet another CADT language / ecosystem. Also note that both crates mentioned in this subthread (regex and rand) are at version 0.x; to a not-really-a-rust-person like me, it signals "experimental API, avoid avoid avoid". I assume that is the reason to start a concerted effort to get everything to 1.0 levels. (I'm mostly commenting because the roadmap under discussion seems to be heading towards the sort of promised stability that I want to see; so having somebody known to be rather close to rust development saying the exact opposite rather unsettles me. Sorry.)