3 ms·

I wasn't talking about the stdlib, I was talking about crates. Rust tries to keep its stdlib small so that crates can evolve on their own (and have alternatives

I wasn't talking about the stdlib, I was talking about crates. Rust tries to keep its stdlib small so that crates can evolve on their own (and have alternatives). I think that's a valid choice, just because needing to fetch a crate for random numbers is different doesn't necessarily mean it is bad. It also means that the versioning can be different -- the URL library can make breaking changes if it wants with a major version bump, and that's okay. Sometimes, a breaking change in the ecosystem is marked as a minor version bump, and sometimes you need to coordinate versioning across crates. This causes breaking changes for downstream users. ------ Most of the actual libs with unstable rust dependencies out there are compiler plugins. "Things depending on unstable internals" exist in many communities and Rust is no different. That doesn't necessarily mean these internals should be stabilized. A big one is clippy, which I maintain. This lints code by hooking directly into compiler APIs, which will never be stable to the extent clippy needs them to be, since that would freeze compiler evolution. Similar tools for other languages either reimplement a mini-parser+typechecker internally, or hook directly into the compiler (gimple passes, etc). There is a solution being worked on for clippy specifically. For tooling/IDEs in general, the Rust compiler will eventually get an "oracle" API that can be queried for type information and whatnot (which probably won't have enough info for clippy to work, but will have enough for general IDE stuff) Another big one is serde, the community serialization library. There is an official one that works pretty well, but serde is better. However, the serialization codegen is done by a plugin. It can also be done with a build script on stable, but this is a bit more unwieldy. Some libraries use the plugin instead of the build script, and often break. There is work going on for a better procedural macro/metaprogramming interface too. That is mostly the extent of things which depend on Rust unstable internals and are used widely. There are a few more things, but they are less used.

steveklabnik 10y ago
> Sometimes, a breaking change in the ecosystem is marked as a minor version bump, ... because it's still a young ecosystem, and a lot of packages aren't at 1.0 yet, so this is valid per semver.
- dbaupp 10y ago
  To be clear, you're saying moving from 0.x.y to 0.(x+1).z is valid to be a breaking change, right? (For other readers, Rust/Cargo uses a---more useful---variant of SemVer where an upgrade from one version to another from assumed to work if the most-significant non-zero numbers are identical, whereas SemVer says that any version number change pre-1.0 could be a breaking change, even 0.1.0 to 0.1.1.)
  - steveklabnik 10y ago
    Semver says that for x.y.z, x == 0 means no guarantees about anything. Cargo currently treats x == 0 as the same as x == 1. I disagree that this is more useful, personally, for exactly this reason.
    - dbaupp 10y ago
      Hm, I'm interested to hear why you think 0.1.0 -> 0.1.1 being considered just as dangerous as 0.1.0 -> 0.2.0 is more useful than treating 0.1.0 -> 0.1.1 as "semver-safe" and having only 0.1.0 -> 0.2.0 be breaking.
mook 10y ago
Thanks for replying! And my view is that having a smaller stdlib and pushing all the responsibility to crates means that the language isn't actually usefully stable, since it means downstream still can't depend on not having breaking changes of its dependencies. The URL library can make breaking changes and have a major version bump; but that means everybody ever that used a URL will need to deal with it, which can be annoying if you happen to be using a crate that does so half a dozen layers in. Saying that a library is broken because its dependencies changed shifts the blame but that doesn't actually help the end developer. I totally understand though; that's more of an artifact of having a young language. I just still find it frustrating. As for unstable compiler plugins: sure, it's looking at dirty compiler internals and whatnot. But that means people are using non-release compilers, and makes it more likely to start using the same in their code. The same could have been achieved by having a compiler version (completely separate from the language version, sort of like how GCC version numbers are decoupled from the C language); instead, we've got instructions lying around encouraging people to use unreleased toolchains. I guess I really just want a stable, battery-included thing to build on top of, but while Rust is exciting it isn't quite there yet. Really thankful for the Rust team (and friends) for working on all this and letting us have a look, though, and looking forward to the day the ecosystem gets there :)

steveklabnik 10y ago

> Sometimes, a breaking change in the ecosystem is marked as a minor version bump, ... because it's still a young ecosystem, and a lot of packages aren't at 1.0 yet, so this is valid per semver.

dbaupp 10y ago
To be clear, you're saying moving from 0.x.y to 0.(x+1).z is valid to be a breaking change, right? (For other readers, Rust/Cargo uses a---more useful---variant of SemVer where an upgrade from one version to another from assumed to work if the most-significant non-zero numbers are identical, whereas SemVer says that any version number change pre-1.0 could be a breaking change, even 0.1.0 to 0.1.1.)
- steveklabnik 10y ago
  Semver says that for x.y.z, x == 0 means no guarantees about anything. Cargo currently treats x == 0 as the same as x == 1. I disagree that this is more useful, personally, for exactly this reason.
  - dbaupp 10y ago
    Hm, I'm interested to hear why you think 0.1.0 -> 0.1.1 being considered just as dangerous as 0.1.0 -> 0.2.0 is more useful than treating 0.1.0 -> 0.1.1 as "semver-safe" and having only 0.1.0 -> 0.2.0 be breaking.

mook 10y ago

Thanks for replying! And my view is that having a smaller stdlib and pushing all the responsibility to crates means that the language isn't actually usefully stable, since it means downstream still can't depend on not having breaking changes of its dependencies. The URL library can make breaking changes and have a major version bump; but that means everybody ever that used a URL will need to deal with it, which can be annoying if you happen to be using a crate that does so half a dozen layers in. Saying that a library is broken because its dependencies changed shifts the blame but that doesn't actually help the end developer. I totally understand though; that's more of an artifact of having a young language. I just still find it frustrating. As for unstable compiler plugins: sure, it's looking at dirty compiler internals and whatnot. But that means people are using non-release compilers, and makes it more likely to start using the same in their code. The same could have been achieved by having a compiler version (completely separate from the language version, sort of like how GCC version numbers are decoupled from the C language); instead, we've got instructions lying around encouraging people to use unreleased toolchains. I guess I really just want a stable, battery-included thing to build on top of, but while Rust is exciting it isn't quite there yet. Really thankful for the Rust team (and friends) for working on all this and letting us have a look, though, and looking forward to the day the ecosystem gets there :)