Email or username:

Password:

Forgot your password?
Top-level
Hailey

a good place to start is with all the 0.x crates which are effectively stable but haven't yet gone 1.0 and made the commitment to stability.

as a result everyone pins a different 0.x version and it's an enormous headache for distro maintainers who would prefer to package a minimal set of versions - ideally a single version - to ease maintenance including security updates for as long as they are supporting a release.

it's a sign of immaturity imo that it's such a widespread view in the community to see this as an outmoded, old school way of doing things that needlessly impedes dev velocity.

3 comments
Hailey

this is often framed as a static vs dynamic linking argument, but that's a red herring. it's actually about maintenance and support. distro maintainers need to be able to bump a dependency in an emergency - regardless of linking strategy. having fewer versions on deck that you have to support makes this a lot easier.

Willow :trans_flag:

@hailey@hails.org for sure. But, because I don’t think that maturity is possible today, I think we just have to statically link everything and waste the space. It’s not even just rust. In fact, I think rust is better than say Python or Ruby. At least with rust your compiling an executable that is statically linked. With Python or Ruby you have to decide to use distro versions of things, user libraries or venvs. And they all suck!

Scherzog von Beast Oil

@hailey I feel like a great part of that is that major versions are seen as a bit more sacred than they should in the Rust community. Maybe it would be useful to do a bit of a push to declare crates that haven't had meaningful API changes in say, a year, to now be on a major version with no changes.

Maybe a convention of including API changes in "stable" versions gated behind a build flag and strictly in an "experimental" module separate from the main API could also solve the velocity issue?

Go Up