Defining the Rust 2024 edition
Defining the Rust 2024 edition
Posted Jan 30, 2024 19:04 UTC (Tue) by atnot (subscriber, #124910)In reply to: Defining the Rust 2024 edition by bluca
Parent article: Defining the Rust 2024 edition
It's a good step, what about source packages.
> Cool, when are you getting started and by which date can we expect to see the fully working result? Or alternatively, when are you going to wire the tens of millions required to pay for such work to happen?
Look, there's plenty of people inside debian who have tried to do this. And the tens of millions figure doesn't get any less ridiculous the more you say it. There's single-person distros who manage this stuff. There's small teams inside debian that manage this (e.g. the go packaging team). The obstacle has always been political, down from the hermit maintainers that get upset and boycott a change if you meddle with their fiefdom by asking them to use a new version of a packaging tool, to the DPLs that run on a platform of not changing anything. Perhaps using your hypothetical tens of millions of dollars to bribe every developer with $10k would help that though.
Posted Jan 31, 2024 11:59 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (4 responses)
What about them?
> Look, there's plenty of people inside debian who have tried to do this. And the tens of millions figure doesn't get any less ridiculous the more you say it. There's single-person distros who manage this stuff. There's small teams inside debian that manage this (e.g. the go packaging team). The obstacle has always been political, down from the hermit maintainers that get upset and boycott a change if you meddle with their fiefdom by asking them to use a new version of a packaging tool, to the DPLs that run on a platform of not changing anything. Perhaps using your hypothetical tens of millions of dollars to bribe every developer with $10k would help that though.
Yes, there are plenty of people who have tried and are trying, and they are all ultimately failing. Not their fault of course, they are fighting an unwinnable, uphill struggle against an hostile ecosystem that couldn't possibly care less about them. So yes, to actually make this viable it would cost tens of millions, because it would need a few dozens of FTE engineers to work on it forever, and labor costs money in this universe.
Posted Jan 31, 2024 14:11 UTC (Wed)
by joib (subscriber, #8541)
[Link] (3 responses)
So perhaps the issue here is that it's the traditional Linux distros that need to adapt to how language ecosystems and software ecosystems work outside the 1980'ies C world? You can tilt at the windmills and scream "CADT!!!" all you want, but the rest of the world is not going to drop whatever they're doing and go back to the good 'ole days of plain C and POSIX sh. There's a lot of crap ideas out there, but all ideas that are different than the 1980'ies C view of the world are not automatically bad.
Posted Jan 31, 2024 14:18 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
....Yeah, how dare folks want to be able to handle their traditional use cases. The same use cases that all of these other language ecosystems stand on top of.
I swear, this really does come off as a "I don't care about the plights of farmers; I get my food from a supermarket!" dismissal.
Posted Jan 31, 2024 14:33 UTC (Wed)
by joib (subscriber, #8541)
[Link]
Just saying that trying to bludgeon the post-2000(-ish) software development world into the shape of the C & sh world is unlikely to be satisfactory to anyone. As there are orders of magnitude more non-distro developers out there, and the distros have little to no leverage over them, it seems this is a fight they're destined to lose.
Posted Feb 3, 2024 1:43 UTC (Sat)
by jschrod (subscriber, #1646)
[Link]
This should go into LWN's quote section.
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition