 I am a big fan of rust and think it's a natural fit for linux into the future. What isn't a natural fit is the npm tier dependency sprawl situation. I really do think we need to listen to what distro maintainers are telling us, because they are the ones who understand how the rubber hits the road when it comes to maintaining and supporting software long term. 10 comments
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. @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!  @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?  @hailey the biggest counterargument to the distro mode of software delivery that I know is that it's not uncommon for distro maintainers to just break packages, or to be hostile to upstream efforts--I've been told to not bother maintaining a debian/ because the first step in Debian is to `rm -rf` it since if they break it, it's on me to fix it, why would I want them to package it? @whitequark I think it's worth noting that the distro mode of delivery isn't for everything. it's for everything on the system that I expect to work and don't want to be responsible for. I'm happy to take on responsibility for the 'application tier' - like building my own ruby - but I don't really want to build my own zlib or gcc or most of the rest of it.  @whitequark @hailey @hailey |
Gregory's Server
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.
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.