Hard Rust requirements from May onward
lists.debian.org
Hard Rust requirements from May onward
1–10 of 797 posts
Re: Hard Rust requirements from May onward
#2The language is tough love, and I think it's important despite what the first respondent has said.
Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage.
I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe languages and defensiveness against adopting modern tooling/languages
Re: Hard Rust requirements from May onward
#3> It's important for the project as whole to be able to
> move forward and rely on modern tools and technologies
> and not be held back by trying to shoehorn modern software
> on retro computing devices.
Rust is the present and the future and it's quite logical that it becomes a key requirement in Linux distributions, but I'm really not convinced by the wording here… This last sentence feels needlessly antagonistic.
Re: Hard Rust requirements from May onward
#4The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…
The pushback is against the acolytes not the language.
If you could separate the language from the acolytes it would have seen much faster adoption.
Re: Hard Rust requirements from May onward
#5The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…
I think the spin that Rust is necessarily the way forward is what is wrong. IMHO Rust has severe problems and what is considered "modern" is mostly taste. We have seen the same thing in the past with a push towards C++, Java, managed languages. What is new is that the free software movement is now controlled so much by corporate interests that some of these changes are pushed through aggressively against the interests of other parts of the community. In the past, if you wanted something changed and there was no agreement, you created a fork and if it was truly better it was eventually adopted by the majority. Nowadays, the companies which fund most of the development aggressively pursue their interests and the part of the community that disagrees is forced out. This justified by with suitable propaganda "not willing to adapt", etc. The whole point of free software should be that I do not have to adapt to some companies's idea of what is modern, if I do not want to. This is why I fled from Microsoft.
Re: Hard Rust requirements from May onward
#6One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html
> Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv).
Wonder what this means for those architectures then?
Re: Hard Rust requirements from May onward
#7One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html > Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv). Wonder what this means for those architectures then?
They are of no commercial interest to Ubuntu.
Re: Hard Rust requirements from May onward
#8> It's important for the project as whole to be able to > move forward and rely on modern tools and technologies > and not be held back by trying to shoehorn modern software > on retro computing devices. Rust is the present and the future and it's quite logical that it becomes a key requirement in Linux distributions, but I'm really not convinced by the wording here… This last sentence feels needlessly antagonistic.
I suspect if this mailing list post doesn't go too under the radar, that last sentence will be a source of major regret.
Re: Hard Rust requirements from May onward
#9One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html > Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv). Wonder what this means for those architectures then?
They are of no commercial interest to Ubuntu.
While that seems like it would be true, is that really relevant to Debian? :)
Re: Hard Rust requirements from May onward
#10The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…
I haven't either, until I read comments on Rust in Linux on social media outside HN.
Apparently, Rust is part of the "woke agenda"