4 ms·

Doesn't the large portion of people using unstable libraries / things depending on unstable internals mean that the versioning isn't covering a large enough API

by mook 10y ago

Doesn't the large portion of people using unstable libraries / things depending on unstable internals mean that the versioning isn't covering a large enough API? I feel like blaming the user isn't really going to help make the ecosystem more stable. (Context: I went through the tutorial at one point and got really fed up that it wasn't possible to do it without involving crates because there wasn't any random number generation in the standard library.) I of course understand that you folks are still working hard on it and it'll come in time; it's just that all other recent languages (Go, Ruby, Python, heck even the . Net and JVM ones) come with a large and usable standard library.

steveklabnik 10y ago
> isn't covering a large enough API? We stabilize lots of stuff every release, but we also don't want to stabilize things that aren't ready. Once we do, we're stuck with that interface forever. A significant portion of nightly users are on it due to compiler plugins, even for libraries that work on stable, because it makes development a bit easier. Stabilizing those immediately would mean stabilizing compiler internals, which is a pretty huge drawback. We have plans for addressing that specifically, as well as for the more general "libraries change" problems. They will come as part of an actual announcement, not a leaked first draft blog post :)
dikaiosune 10y ago
I came from languages where a big standard library was de rigeur (python, java), and I quite like rust's approach personally. For one thing, having RNG in the standard library would make it much harder with rusts stability guarantee to iterate on the API design in meaningful ways. For another, it's way easier to maintain external dependencies in a rust project than in others. Cargo is like night and day compared to pip, for example.
- mook 10y ago
  Yes, it's harder to iterate on API design once it's in the stable API. But that's the point, basically; it's harder to keep code working if the thing you're using keeps iterating. And yeah, cargo is really nice. I just think the part where you have to go to it for all the things, with no direction on which alternative is (API- / crash-) stable, maintained, etc. is frustrating. That's the thing a standard library gives me - curation.
Manishearth 10y ago
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

by mook 10y ago

steveklabnik 10y ago

> isn't covering a large enough API? We stabilize lots of stuff every release, but we also don't want to stabilize things that aren't ready. Once we do, we're stuck with that interface forever. A significant portion of nightly users are on it due to compiler plugins, even for libraries that work on stable, because it makes development a bit easier. Stabilizing those immediately would mean stabilizing compiler internals, which is a pretty huge drawback. We have plans for addressing that specifically, as well as for the more general "libraries change" problems. They will come as part of an actual announcement, not a leaked first draft blog post :)

dikaiosune 10y ago

I came from languages where a big standard library was de rigeur (python, java), and I quite like rust's approach personally. For one thing, having RNG in the standard library would make it much harder with rusts stability guarantee to iterate on the API design in meaningful ways. For another, it's way easier to maintain external dependencies in a rust project than in others. Cargo is like night and day compared to pip, for example.

mook 10y ago
Yes, it's harder to iterate on API design once it's in the stable API. But that's the point, basically; it's harder to keep code working if the thing you're using keeps iterating. And yeah, cargo is really nice. I just think the part where you have to go to it for all the things, with no direction on which alternative is (API- / crash-) stable, maintained, etc. is frustrating. That's the thing a standard library gives me - curation.

Manishearth 10y ago

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