Hard Rust Requirements From May Onward
Posted2 months agoActiveabout 2 months ago
lists.debian.orgTechstoryHigh profile
heatedmixed
Debate
85/100
RustDebianLinuxProgramming Languages
Key topics
Rust
Debian
Linux
Programming Languages
Debian is considering making Rust a hard requirement for new packages, sparking debate about the language's maturity, compatibility, and the project's direction.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
65
0-6h
Avg / period
17.8
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Nov 1, 2025 at 3:31 AM EDT
2 months ago
Step 01 - 02First comment
Nov 1, 2025 at 4:38 AM EDT
1h after posting
Step 02 - 03Peak activity
65 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 5, 2025 at 6:16 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45779860Type: storyLast synced: 11/20/2025, 8:04:59 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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
If you could separate the language from the acolytes it would have seen much faster adoption.
Rust haters seem strangely obsessed.
Well, this is a great example. People complaining about the community are labeled as people complaining about the language.
Do you not see the problem here?
Because it literally says "Rust haters"; not "Rust community haters".
Are you saying that when someone refers to "Rust", they mean the community and not the language?
Maybe. What does that have to do with the Rust community having such a poor reputation compared to other communities?
That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nevertheless.
Rust is already pretty successful adoption wise. It’s powering significant parts of the internet, it’s been introduced in 3 major operating systems (Windows, Linux, Android), many successful companies in a variety of domains have written their entire tech stack in it. Adoption as measured by crates.io downloads has doubled every year for the last 10 years.
Now I’m imagining how much more widely Rust would be used if they had adopted your visionary approach of never saying anything positive about it.
No, it's the people who have given rise to the multiple Rust memes over the years.
I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their communities.
After all, for quite a few years every thread on forums that mentioned C or C++ was derailed by Rust proponents. I didn't see C++ users jumping into Rust threads posting attacks, but there are many examples of Rust users jumping into C++ or C threads, posting attacks.
> That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nevertheless.
Well, the fact that Rust is an outlier in this sample should tell you everything you need to know; other up-and-coming languages have not, in the past, gotten such a reputation.
Because you’re young or you weren't around in 2010 when Go was gaining adoption. Same shit back then. People said “I like the language, it’s quite useful” followed by tirades from people who thought it was the end of human civilisation. It had exactly the reputation you speak of. (“DAE generics???”)
Eventually the haters moved on to hating something else. That’s what the Rust haters will do as well. When Zig reaches 1.0 and gains more adoption, the haters will be out in full force.
I've been working as a programmer since the mid-90s
>> I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community.
> People said “I like the language, it’s quite useful” followed by tirades from people who thought it was the end of human civilisation.
And? That's not the same as having a hostile community. I never saw Go proponents enter C# or Java discussions to make attacks against the programmers using C# or Java like I saw constantly wirh Rust proponents entering C or C++ discussions and calling the developers dinosaurs, incompetent, etc.
Hostile according to who? According to the haters, maybe. I’m sure the Go community was called “hostile” by haters back in the day.
Look at the drama created by Linux maintainers who were being insanely hostile, coming up with spurious objections, being absolute asshats - to the point where even Linus said enough was enough. The Rust for Linux members conducted themselves with dignity throughout. The Linux subsystem maintainers acted like kindergarteners.
But of course, haters will read the same emails and confirmation bias will tell them they’re right and Rust is the problem.
Keep hating.
I also notice that these language debates are very much generational. That has a few consequences. First is that older devs have thicker skin. Second, older devs are more wary of the big promises made by Rust. Whether you like it or not, the push for Rust very much comes across as naivete as much as anything to older, more experienced devs who have seen this type of thing before.
You can't write a device driver without manipulating memory directly. A OS Kernel has to manipulate memory directly by definition. Most academic research into memory safe languages is mixed with a high amount of null results (meaning it doesn't work). Yet the Rust folks push it as the 'one true way'. Meanwhile, most Rust OpenSource projects are abandoned currently.
Its not hate, its pointing out track record and avoiding repeating past mistakes due to painful experiences in our youth. Your determination to repeat past mistakes doesn't come across as enlightenment like you think it does.
The Android team shipped a more secure operating system to billions of people. Their lives are better because of choosing more Rust and Kotlin and less C++.
> You can't write a device driver without manipulating memory directly.
This isn’t the gotcha you think it is. Check out this upstreamed driver - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
This is a successful kernel driver that powers all IPC in Android. This is the most load bearing component in Android, especially because it is constantly being attacked by malware. It manipulates memory just fine actually.
In your hurry to dismiss Rust, you haven’t done a technical evaluation of it. If you had you wouldn’t conflate memory safety with a lack of memory manipulation. You’ve taken the intellectually lazy shortcut of dismissing a new thing because no new thing can be as good as the old things.
I write all this not to convince you to change your mind. I don’t think that’s possible. I write it so anyone else reading this will avoid your thought process. I don’t need to convince you, because this industry is moving ahead regardless.
We are all aware of unsafe. We are also aware that all those assurances of safety go away in those circumstances.
This is cherry-picking. I didn't say all research papers, just most. This is a very specific circumstance. Under specific circumstances these ideas will work.
This example is one where the replaced code wasn't that old, on a very specific set of hardware and in a rather specific case. Its basically the ideal set of conditions for a rewrite. But there are plenty of cases where attempts to swap in Rust aren't being done in ideal conditions like this. I doubt switching to Rust is never a good idea. I also doubt switching to Rust is always a good idea.
PS The problem is partly the way you write. I criticize ideas. You criticize me. That's a big part of why you get pushback.
I was there, and no it wasn't. The Go community didn't jump into every programming discussion throwing around accusations of dinosaur, insecurity, etc.
There absolutely are, and have been. You could say it's a reaction. I don't want to argue about who started it.
I agree with you that if the Rust community has gained such a peculiar reputation, it's also due to valid reasons.
I have rarely seen an argument that pushes back against Rust with actual alternative solutions to the problems the rust proponents are trying to solve. It is mostly a bunch of old people letting the perfect be the enemy of the good.
> I didn't see C++ users jumping into Rust threads posting attacks, but there are many examples of Rust users jumping into C++ or C threads, posting attacks.
I already seen this with Zig. And even without language communities. Look at this whole thread. Look in to the mirror. Regularly when Rust is mentioned on HN. Anti-Rust cult comes to complain that there is Rust.
Even if someone just posts "I have made this with Rust" - then this cult comes and complains "why do you need to mention Rust?!". Like look at your self. Who hurt you?
Pointing out that the Rust community has gained such a poor reputation while other communities have not requires "looking into the mirror"?
Good news: you can. And that's why it has had fast adoption.
(those advocating for Rust in "meme-like" ways are not generally the same people actually developing the Rust compiler or the core parts of it's ecosystem)
Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool.
I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust is as a language.
Of course most people aren't smart enough for the language so they have to use inferior algol languages like rust.
This is someone who says things like
>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.
While on company time.
Yes well, glad to hear there’s no one bullying people there!
Elitism is it's own form of bullying and needs to be treated as such.
I don't particularly like large swaths of humanity, but I also try hard not to be elitist towards them either. I'm not always successful, but I make a strong effort as my family raised me to be respectful to everyone, even if you don't personally like them.
[1] https://github.com/johnperry-math/AoC2023/blob/master/More_D...
It seems like Ada more or less has to have memory safety bolted on -- that is what SPARK does -- and it's not clear that Ada's bias towards OO is better than Rust's bias towards functional programming.
Are you talking about features like type inference (so the Rust code could be less clear, since types are not always written out)?
you see, GP did not speak in relative terms, but absolutely: They believe Rust has problems. They did not suggest that problems with programming languages are basically all fungible, that we should sum up all problems, compare different languages, and see which ones come out on top.
Nobody is being forced out of the community, you can fork and not adopt the changes if you want. Thats the real point of free software, that you have the freedom to make that choice. The whole point of free software was never that the direction of the software should be free from corporate control in some way, the maintainers of a project have always had the authority to make decisions about their own project, whether individual or corporate or a mix.
You describe it that way, but that's not how the world in general works in practice. You do things based on majority.
False claims don't really make the claims about the evils of Rust more believable.
Requiring full consensus for decisions is a great way to make no decisions.
What are some concrete cases you can point to where a decision was made with full consensus? Literally everyone agreed? All the users?
I'm not sure many projects have ever been run that way. I'm sure we've all heard of the Benevolent Dictator for Life (BDfL). I'm sure Linus has made an executive decision once in a while.
Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that.
C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad code and accepts all the good code without making any code changes, which of course isn't going to happen.
Garbage collection is a huge dealbreaker for the people still on C/C++. This immediately rules out the vast majority of memory-safe languages. What is left is pretty much only Zig and Rust. Both have their pros and cons, but Rust seems to be more mature and has better community adoption.
The way I see it, the pro-memory-safety crowd is saying "There's a giant hole in our ship, let's use Rust to patch it", and the anti-Rust crowd yells back "I don't like the color of it, we shouldn't repair the hole until someone invents the perfect solution". Meanwhile, the ship is sinking. Do we let the few vocal Rust haters sink the ship, or do we tell them to shut up or show up with a better alternative?
> Garbage collection is a huge dealbreaker for the people still on C/C++.
The problem is not so much GC itself, but more like pervasive garbage collection as the only memory management strategy throughout the program. Tracing GC is a legit memory management strategy for some programs or parts of a program.
The reason memory safety is interesting in the first place (for practical, not theoretical reasons) is that it is a common cause of security vulnerabilities. But spatial memory safety is a bigger problem than temporal memory safety, and Zig does offer spatial memory safety. So if Rust's memory safety is interesting, then so is the memory safety Zig offers.
I'm a rabid software correctness advocate, and I think that people should acknowledge that correctness, safety (and the reasons behind it) are much more complex than the binary question of what behaviours are soundly disallowed by a language (or ATS advocates would say that from that their vantage point, Rust is just about as unsafe as C, and so is completely uninteresting from that perspective).
The complexity doesn't end with spatial vs temporal safety. For example, code review has been found to be one of the most effective correctness measures, so if a language made code reviews easier, it would be very interesting from a correctness/security perspective.
The whole Rust ecosystem is heavily biased towards prioritising memory safety and "safe by construction" .
This is evident in the standard library, in how crates approach API design, what the compilation defaults are, ...
In 6+ years of using Rust the only time I had to deal with segfaults was when working on low level wrappers around C code or JIT compilation.
Zig has some very interesting features, but the way they approach language and API design leaves a lot of surface area that makes mistakes easy.
I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are also much weaker in such situations so that’s why I find Zig very interesting.
No oob access, no wacky type coercion, no nullptrs solves such a huge portion of my issues with C. All I have to do is prove my code doesn’t have UAF (or not if the program isn’t critical) and I’m basically on par with Rust with much less complexity.
I don’t actually mind Rust when I was able to write in safe user land, but for embedded projects I’ve had a much better time with Zig.
> The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably.
My first thought is that it is kind of like talking about gradually improving manual memory allocation in Java. C and C++ are fundamentally memory unsafe; it's part of their design, to offer complete control over memory in a straightforward, direct way.
No it is not. We have a lot of amazing and rock solid software written in C and C++. Stuff mostly works great.
Sure, things could be better but there is no reason why we need to act right now. This is a long term decisions that doesn't need to be rushed.
> What is left is pretty much only Zig and Rust.
We had Ada long before Rust and it is a pretty amazing language. Turns out security isn't that important for many people and C++ is good enough for many projects apparently.
There is also D, Nim, Odin and so on.
> Garbage collection is a huge dealbreaker
It isn't. We had Lisp Machines in the 80s and automatic garbage collection has vastly improved these days. So I wouldn't rule those out either.
In short, no the ship is not sinking. There are many options to improve things. The problems is once you depend on rust it will be hard to remove so it is better to think things through because rushing to adopt it.
I haven't seen this from Rust. Obviously lots of us think that Rust is the way forward for us but I think the problem you're talking about is that nobody offered any alternatives you liked better and that's not on Rust.
If Bob is ordering pizza for everybody who wants one, it is not the case that "Pizza is necessarily the way forward", and it's not Bob's fault that you can't have sliders, I think if you want sliders you're going to need to order them yourself and "Pizza is the way forward" is merely the default when you don't and people are hungry.
Dave Abraham's Hylo is an example of somebody offering to order sushi in this analogy. It's not yet clear whether Dave knows a Sushi place that delivers here, or how much Sushi would be but that's what having another way forward could look like.
In C++ they've got profiles, which is, generously, "Concepts of a plan" for a way forward and in C... I mean, it's not your focus, but nobody is looking at this right? Maybe Fil-C is your future? I note that Fil-C doesn't work on these obsolete targets either.
This assumes there wasn't agreement.
And if so, what would 'eventually adopted by the majority' mean. Is this announcement not that?
I'll wait.
This hasn’t changed.
Apparently, Rust is part of the "woke agenda"
Personally, I'm simply bothered by the fact that (one of?) the most famous figure of Rust on Linux and Rust Forever consumes and advocates for pornography that's illegal in my country, without being held accountable by the community.
From what I could piece together, the only group who ever cried wolf about this is a forum full of contemptious little angry men who spend weeks researching people they hate on the internet. No one seems to want to touch the subject from fear of being associated with them.
I'll give it to you, this is not a great time.
If some form of speech is illegal in your country it does automatically mean it should be illegal for the whole world or that it is wrong or that the world-wide community should adhere to standards specific to your country. Even if that country is USA.
In other words, nobody should give a flying f about open source developers porn preferences.
I'm pretty suspicious of demands for communities to hold people accountable, especially when the community in question is a loose group of people who mostly communicate online and are united by their shared use of a specific programming technology; and who probably disagree on all sorts of other issues, including contentious ones.
Your abhorrent personal opinion of another individual has no place in a technical discussion.
If you opt into something with as high a barrier to entry and necessary time commitment as a programming language, you naturally also opt into the existing community around that language, because that will be where the potential contributors, people to help you solve issues, and people you have to talk to if you need the language or ecosystem to move in some direction will hail from. In turn, the community will naturally get to impose its own values and aesthetic preferences onto you, whether by proactively using the position of relative power they have over you, or simply by osmosis. As it happens, the community surrounding Rust does largely consist of American progressives, which should not be surprising - after all, the language was created by an American company whose staff famously threatened mutiny when its own CEO turned out to offend progressive sensibilities.
As such, it is natural that bringing Rust into your project would over time result in it becoming more "woke", just like using Ruby would make it more likely that you attract Japanese contributors, or targeting Baikal CPUs would result in you getting pulled into the Russian orbit. The "woke" side themselves recognises this effect quite well, which is why they were so disturbed when Framework pushed Omarchy as a Linux distribution.
Of course, one needs to ask whether it is fair to insinuate premeditation by calling a mere expected effect an "agenda". Considering the endlessly navel-gazing nature of the culture wars, I would find it surprising if there weren't at least some people out there who make the same observation as above, and do think along the lines that driving Rust adoption is [also] a good thing because of it. Thus, Rust adoption does become, in a sense, part of the "woke agenda", just as Rust rejection becomes, perhaps even more clearly so, part of the "chud agenda".
The general temperature of politics in FOSS, I think, is not obviously lower than before: just in terms of things that made it onto HN, in the past month or so alone we have seen the aforementioned kerfuffle about dhh (the leader? founder? of Ruby on Rails), his projects and their detractors, and the wrestling over control between NixOS's board and its community moderators who were known for prosecuting political purges and wanted to assert formal authority over the former.
I think this analysis is basically accurate - there's no conspiracy or even deliberate agenda going on, it's just that the community surrounding Rust happens to have (at the moment, anyway) a relatively high number of American progressives, many of whom are openly interested in imposing American progressive ideological norms in spaces they care about (which is basically what we mean by the term "woke").
I think Rust is a good software tool and I would like to see it be as widely adopted and politically-neutral as C is, and used in all sorts of projects run by all sorts of people with all sorts of other agendas, political or otherwise. Consequently, I would like to see people and projects who do not agree with American progressive norms adopt the language and become active users of it, which will help dilute the amount of Rust users who are progressives. I myself am not an American political progressive and I have lots of issues with the stated politics of many well-known Rust developers.
As far as i read on HN, the only memory safe language discused on HN is rust and mostly with childish pro arguments.
EDIT: from a brief search: it doesn't.
For a language to be memory safe it means there must be no way to mishandle a function or use some object wrong that would result in an "unsafe" operation (for Rust, that means undefined behavior).
That is to say the default is safe, and you are given an escape hatch. While in something like c/c++ the default is unsafe.
I'd also like to add that program correctness is another separate concept from language safety and code safety, since you could be using an unsafe language writing unsafe ub code and still have a correct binary.
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.
A nostalgia-fuelled Linux distro, maybe using a deliberately slimmed down or retro kernel, and chosen software could make a lot more sense than keep trying to squeeze Debian onto hardware that was already obsolete at the turn of the century while also promoting Debian as a viable choice for a brand new laptop.
Solved problem:
United States Patent Application 3127321 Date of Patent March 31, 1964 NUCLEAR REACTOR FOR A RAILWAY VEHICLE
alpha, hppa, m68k and sh4
To be fair, lots of people did use Motorola 68xxx CPUs when those were new, it's just that it was 40+ years ago in products like the Commodore Amiga. The SH4 is most popularly connected to the Dreamcast, Sega's video game console from back when Sega made video game consoles.
The Alpha and PA Risc were seen in relatively recent and more conventional hardware, but in much tinier numbers, and when I say relatively I mean early this century, these are not products anybody bought five years ago, and when they were on sale they were niche products for a niche which in practical terms was eaten by Microsoft.
> 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?
https://mastodon.social/@juliank
>Senior Engineer at Canonical.
sure some are also payed by a foundation. Which is also payed by companies but with a degree of decoupling of influence.
and some pay them self, e.g. fully voluntary work, but most dev can't afford to do so on a long term, high time commitment manner. So a lot of major changes and contributions end up coming from people directly or indirectly "payed" by some company.
and that's pretty common across most "older, larger, sustainable and still developed OSS"
They will be rebranded as "retro computing devices"
I’m not in the Debian world, but those do seem to me like the types of systems that could use their own specialized distros rather than being a burden to the mass market ones. It’s not as if you could run a stock configuration of any desktop environment on them anyway.
Does or should debian care? I don't know.
But I'm not sure. I think the new Rust dependencies are good. In an ideal world, the people who care about niche systems step up to help Rust target those systems.
I’m actually the person who added the m68k target to the Rust compiler and was also one of the driving forces of getting the backend into LLVM.
Generally speaking, getting a new backend into the Rust compiler is not trivial as it depends on LLVM support at the moment which is why asking someone to just do it is a bit arrogant.
Luckily, both rustc_codegen_gcc and gccrs are being worked on, so this problem will be resolved in the future.
I'll try to rephrase: if we never want to give up support for a platform we've supported in the past, then I think we only have two options: (1) never adopt new technology where support for said platforms doesn't come for free, or (2) leave it up to those who care about the niches to ensure support.
Neither is pain-free, but the first seems like a recipe for stagnation.
It's lovely to see the two alternative compiler paths for Rust moving forward though! Thank you!
I don’t get the fuzz around the “retro computing” verbiage. I doubt anyone is actually running Debian on these devices out of necessity, someone who plays baroque music in reconstructed period instruments won’t balk at being called an “early music” enthusiast.
(LLVM even used to have an in-tree DEC Alpha backend, though that was back in 2011 and not relevant to any version of Rust.)
[0] Looks like there is basic initial support but no 'core' or 'std' builds yet. https://doc.rust-lang.org/rustc/platform-support/m68k-unknow... This should potentially be fixable.
[1] https://github.com/rust-lang/rustc_codegen_gcc
yes, from a pure code generation aspect
no, as all conditional-compiled platform specific code is missing.
So using it with #[no_core] should work (assuming the WIP part of the backend isn't a problem). But beyond that you have to first port libcore (should be doable) and then libstd (quite a bunch of work).
(not relevant to Debian, but cool that it's already possible)
Who is actually _running_ Debian Trixie on these platforms now?
It is counter-intuitive to me that these platforms are still unofficially supported, but 32-bit x86 [edit: and all MIPS architectures!] are not!
I am emotionally sad to see them fall by the wayside (and weirdly motivated to dig out a 68k Amiga or ‘very old Macintosh’ and try running Trixie…) but, even from a community standpoint, I find it hard to understand where and how these ports are actually used.
It’s just a bit annoying that Rust proponents are being so pushy in some cases as if Rust was the solution to everything.
This is not intended to bash you or anyone else who’s working on it - I think it’s a cool project (I have in the recent past got an 86duino ZERO to run Gentoo, just to see if an obscure old-ish piece of hardware can be useful with modern Linux on it - and it can). I do understand the reason a project like Debian might not want to have to spend resources even just to make it easier to do though.
https://sandervanderburg.blogspot.com/2025/01/running-linux-...
I didn't find what Debian version they tried but I think it's implied it's a recent version. They ran into memory issues. They had only 48MB while the recommendations are to use 64MB. It did boot though until it threw errors because of memory constraints.
They got a working system by trying Debian 3.1 though.
It's been somewhat useful for finding weird edge cases in software where for whatever reason, it doesn't reproduce easily on AArch64 or x86, but does there. (Or vice-versa, sometimes.)
I don't know that I'd say that's sufficient reason to motivate dozens of people to maintain support, but it's not purely academic entertainment or nostalgia, for that.
It looks like the last machines of each architecture were released:
Alpha in 2007
HP-PA in 2008
m68k in pre-2000 though derivatives are used in embedded systems
sh4 in 1998 (though possible usage via "J2 core" using expired patents)
This means that most are nearly 20 years old or older.
Rust target triples exist for:
m68k: https://doc.rust-lang.org/nightly/rustc/platform-support/m68... and https://doc.rust-lang.org/nightly/rustc/platform-support/m68... both at Tier 3.
(Did not find target triples for the others.)
If you are using these machines, what are you using them for? (Again, genuinely curious)
[0] https://en.wikipedia.org/wiki/I386
595 more comments available on Hacker News