27 ms·

Hard Rust requirements from May onward

• CartwheelLinux 11mo ago
  The 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
  • lelanthran 11mo ago
    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.
    • kaoD 11mo ago
      In my experience from these threads, there are more people polluting the discussion by complaining about Rust "acolytes" than actual acolytes. Rust haters seem strangely obsessed.
      • lelanthran 11mo ago
        > 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?
        • deleted 11mo ago
          [deleted]
        • whilenot-dev 11mo ago
          I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"?
          • lelanthran 11mo ago
            > I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"? 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?
            • whilenot-dev 11mo ago
              Yes, you're half way there.
        • timeon 11mo ago
          If you change it to "Rust community haters seem strangely obsessed.", it is still valid.
          • lelanthran 11mo ago
            > If you change it to "Rust community haters seem strangely obsessed.", it is still valid. Maybe. What does that have to do with the Rust community having such a poor reputation compared to other communities?
        • tayo42 11mo ago
          Rust language and rust community are intertwined. It's a design descion from the language creators
    • testdelacc1 11mo ago
      Acolytes being the people talking positively about their experience using a language and the strengths they think it has. So the people with positive opinions should say nothing at all, and the people with negative opinions should be free to share. And somehow, you think this will lead to faster adoption. 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.
      • lelanthran 11mo ago
        > Acolytes being the people talking positively about their experience using a language and the strengths they think it has. 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.
        • testdelacc1 11mo ago
          > I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. 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.
    • nicoburns 11mo ago
      > If you could separate the language from the acolytes it would have seen much faster adoption. 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)
  • uecker 11mo ago
    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.
    • Mond_ 11mo ago
      > IMHO Rust has severe problems and what is considered "modern" is mostly taste. 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.
      • noosphr 11mo ago
        I'm very happy with common lisp for fast code. Of course most people aren't smart enough for the language so they have to use inferior algol languages like rust.
        • AlotOfReading 11mo ago
          No need to sully CL with this kind of elitism. Any language you need to be a genius to use is a bad language. That's one of the fundamental issues with C. We're all imperfect idiots some of the time and one instance of undefined behavior breaks any guarantees the language gives you.
  • tcfhgj 11mo ago
    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"
    • hofrogs 11mo ago
      Yep, I noticed that under a lot of videos mentioning rust in kernel, or rust in general there's a high chance that the comment section will just be straight up lifted from 4chan pol or a similar place
      • hsbauauvhabzb 11mo ago
        Is there any particular reason for this? Do they not agree with the code of conduct more than normal?
        • noisem4ker 11mo ago
          Complete disagreement with codes of conduct and the typical political orientation of their proponents. Also, pure contrarian spirit.
    • alt187 11mo ago
      People are (understandably) sick of the fact that for whatever reason, the biggest proponents of Rust are insufferable. 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.
      • JuniperMesos 11mo ago
        I'm genuinely not sure who you're talking about or whether this is an accurate characterization of their views. For that matter, I'm not sure what country you're in and whether I myself agree with that country's laws about whatever kind of pornography this is. Certainly plenty of countries I don't live in and have no ties to have laws I disagree with or violate routinely. 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.
  • TheChaplain 11mo ago
    [flagged]
    • Ygg2 11mo ago
      Tell me you haven't used Rust without telling me you haven't used Rust.
    • mrweasel 11mo ago
      For me it actually is the language. While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded. If the apt tool chains is one of those places I'll leave for the Debian developers to determine, but for decompression tools I can see a benefit. If Rust should be the language of choice, preferably not. The syntax is awful, the language is complicated and Rust programs seems to collect dependencies at the same rate as JavaScript. Where I might agree with you is that Rust seems to attract a certain type of people. They write absolutely brilliant software, but like the Rust compile, they are rather particular with what input they'll accept. In the end I don't really care what apt is written in, I'm not the one writing the code. I just use the tool. It would be sad if some platforms are left behind, because the Rust developers don't care about them and not because they're no longer useful.
      • hulitu 11mo ago
        > While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded. Yes. It is. Just write the code and show us that it is good.
    • bmicraft 11mo ago
      Ironically, the people hating on it (and usually without any technical arguments) act way more cultish. At least it looks that way to my not-rust-using self
  • hulitu 11mo ago
    > I don't quite understand the pushback against memory safe languages As far as i read on HN, the only memory safe language discused on HN is rust and mostly with childish pro arguments.
    • zozbot234 11mo ago
      Java and C# are memory safe languages, as are common interpreted languages like Python and Ruby. Even JavaScript is memory safe, barring the possibility of subtle JIT bugs that may practically impact such safety.
      • kaoD 11mo ago
        But op means memory and data safe, without a GC nor a runtime, so it can be used as a systems programming language. For "some reason" people only talk about Rust in this space!
        • zozbot234 11mo ago
          Swift is also memory safe in that sense.
          • hypeatei 11mo ago
            Swift uses Automatic Reference Counting (ARC) which is a form of garbage collection.
            • kaoD 11mo ago
              Now I'm curious, how does it GC cycles, if at all? EDIT: from a brief search: it doesn't.
            • kaoD 11mo ago
              Not sure why you're downvoted, RC is definitely a form of GC even if not a tracing GC.
          • 11mo ago
  • krater23 11mo ago
    The pushback comes from the idea to rewrite all old tools in another language just because you can. Instead of creating new projects and using the new language it feels like the most rust projects are rewrite from old projects. And the most projects you have read about on hacker news in the last year 'I made xy, but in rust' are already abandoned. It's just a trend to write something already existing in Rust just to learn the language and then release it for productive use.
• littlestymaar 11mo ago
  > 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.
  • jchw 11mo ago
    I suspect if this mailing list post doesn't go too under the radar, that last sentence will be a source of major regret.
    • noobermin 11mo ago
      And if it is it absolutely is indicative of their opinion and absolutely deserved.
  • IshKebab 11mo ago
    Feels accurate to me. He's clearly anticipating the "but how will I run Debian on my PDP-11??" naysayers that always try to derail things.
    • tialaramex 11mo ago
      Right. I do have some nostalgia for installing Linux on a brand new PC which had less total RAM than my computer today has cache, but we need to be clear eyed about what makes sense for a maintained piece of software. I also have feelings about steam trains, but burning coal is not a sensible way to power a train in 2025. 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.
      • BobBagwill 11mo ago
• justinclift 11mo ago
  One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html 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?
  • uecker 11mo ago
    They are of no commercial interest to Ubuntu.
    • justinclift 11mo ago
      While that seems like it would be true, is that really relevant to Debian? :)
      • noosphr 11mo ago
        The person making the post is getting paid by Ubuntu.
        • apples_oranges 11mo ago
          Needs a perhaps with question mark or some proof.
          • noosphr 11mo ago
            You could just read his signiture in the mailing list. https://mastodon.social/@juliank https://mastodon.social/@juliank >Senior Engineer at Canonical.
            • julian-klode 11mo ago
              Yes that's true and there's synergies but keep in mind I also have a personal mind
• noosphr 11mo ago
  I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries. But the people who use the language have an amazing talent to make people on the fence hate them within half a dozen sentences. They remind me of Christian missionaries trying to convert the savages from their barbarous religions with human sacrifice to the civilised religion with burning heretics.
  • noobermin 11mo ago
    [flagged]
    • kaoD 11mo ago
      Well, so far this thread has 0 people shilling Rust, a couple shilling Common Lisp and a bunch complaining about Rust shills (you included). Makes you think, huh?
      • testdelacc1 11mo ago
        [flagged]
  • Antibabelic 11mo ago
    Many programmers feel the same way about Lispers. It's best to set aside your gut feelings about the community and think primarily about the technical and organizational merits and disadvantages of the technology.
    • noosphr 11mo ago
      Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.
      • mdhb 11mo ago
        Not a Rust or even a systems language guy but it’s not “for some reason”. The reason is actually incredibly clear and about removing the single largest surface area of security problems in the entire history of Linux.
• nikanj 11mo ago
  The language is incredibly frank, and I agree with it completely. The retro-computing hobby doesn't need the ability to run contemporary operating systems. It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!). x64 Debian is a bit more modern, and you must splurge for a CPU from 2005 (Prescott) to get the plethora of features it requires
  • Antibabelic 11mo ago
    Is it just the "retro-computing hobby"? There could still be businesses who might need support for old machines, especially in developing countries. I don't know the actual situation though, I'm open to the idea that my suggestion is insane.
    • mirashii 11mo ago
      No, it’s a valid question, and one that I’m sure will get some answers in the coming days and weeks as the discussion on adding this requirement continues, but in some sense, it’s beside the point. The cost of supporting this old hardware for businesses or hobbyists isn’t free. The parties that feel strongly that new software continue to be released supporting a particular platform have options here, ranging from getting support for those architectures in LLVM and Rust, pushing GCC frontends for rust forward, maintaining their own fork of apt, etc.
    • tsimionescu 11mo ago
      It's much more common to find businesses running on very old hardware in developed countries, not in developing ones. Developing nations basically didn't use computers 20-30 years ago, there's no random remnants from that era beyond some extreme tail end. And, given how the PC & server market evolved in the 2000s and 2010s, it was cheaper to buy a then-current x86 than to import some ancient Alpha system from wherever. Especially so since software licenses didn't really exist in those days in developing countries - even government institutions often ran pirated software without a second thought.
      • baobun 11mo ago
• troupo 11mo ago
  [flagged]
• einpoklum 11mo ago
  That seems like a bad idea to me: Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized, and IIANM itself has further dependencies. I wonder whether platform compatibility won't be jeopardized, either. I would be worried if even C++ dependencies were added for basic system utilities, let alone something like Rust. Now, granted, I'm not an expert on distro management, bootstrapping etc. so maybe I'm over-reacting, but I am definitely experiencing some fear, uncertainty and doubt here. :-(
  • mirashii 11mo ago
    > Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized, This is the status quo and always has been. gcc has plenty of extensions that are not part of a language standard that are used in core tools. Perl has never had a standard and is used all over the place.
    • einpoklum 11mo ago
      If you're designing an OS distribution, you would have your base system written adhering strictly to language standards and without relying on flakey extensions (not that GCC C extensions are flakey, I'm guessing most/all of them are stable since the 1990s), and minimizing reliance on additional tools. For example, IIUC, you can build a perl interpreter using a C compiler and GNU Make. And if you can't - GCC is quite bootstrappable; see here for the x86 / x86_64 procedure: https://stackoverflow.com/a/65708958/1593077 https://stackoverflow.com/a/65708958/1593077 and you can get into that on other platforms anywhere along the bootstrapping chain. And then you can again easily build perl; see: https://codereflections.com/2023/12/24/bootstrapping-perl-without-a-compiler/ https://codereflections.com/2023/12/24/bootstrapping-perl-wi...
      • pseudalopex 11mo ago
        The procedure to produce GCC you cited was 13 steps. Many of the tools were made after distributions required GCC. And a similar procedure could produce a Rust compiler.
• teaearlgraycold 11mo ago
  Why do these matters often become such personal and ideological debates?
  • JuniperMesos 11mo ago
    The writer Gwern has a good essay attempting to answer this question: https://gwern.net/holy-war https://gwern.net/holy-war
• cmm11 11mo ago
  If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725 https://github.com/keepassxreboot/keepassxc/issues/10725
  • 0x000xca0xfe 11mo ago
    What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.
    • mouse_ 11mo ago
      You misunderstand, see; these people are corporate saboteurs.
    • cmm11 11mo ago
      Just annoys me that he calls features "crap" just because he likely doesn't use them personally and ends that post with a random sentence claiming such a version "increases the risk of drive-by attacks" with zero evidence. The developer explains the features aren't plugins and aren't even enabled by default. Arrogance from maintainers like this from within Debian is what will hurt it far more than any external entity.
      • 0x000xca0xfe 11mo ago
        Exactly, this rude and insulting behavior is why many people shy away from open source. Not everybody has the time and mental capacity to engage in ideological battles about software architecture. We should really hold more value to keeping existing user setups working. Breakages are incredibly damaging and might very well have a bigger impact than insecure defaults.
      • 11mo ago
• mid-kid 11mo ago
  Wouldn't it make sense to wait for (or support) one of the rust-for-GCC ports to become viable? As far as I understand, rust in the kernel won't become mandatory either until it's supported by GCC, and as a boon, with multiple implementations you can be more certain that the language won't move as fast and break things anymore. There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically. Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare?
  • julian-klode 11mo ago
    Ports are not part of Debian and particularly don't release with Debian, they only ship unstable.
    • mid-kid 11mo ago
      changed the wording a little, thanks
  • Measter 11mo ago
    There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically. The GCCRS project can't even build libcore right now, let alone libstd. In addition, it is currently targeting Rust 1.50's feature set, with some additions that the Linux kernel needs. I don't see it being a useful general purpose compiler for years. What's more likely is that rustc_codegen_gcc, which I believe can currently build libcore and libstd, will be stabilised first.
  • Denvercoder9 11mo ago
    > Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare? These architectures aren't being removed from Debian proper now, they already were removed more than a decade ago. This does not change anything about their status nor their ability to get back into Debian proper, which had already practically vanished.
• krautburglar 11mo ago
  I think polyglot causes more problems than it solves. It is gross how many different toolchains and package managers it now takes to build a distro. One person wants python, another wants node, another wants go, and now this. with node we traded buffer overflows for supply chain attacks. If they don’t want C, it would be better to start fresh. Robert Morris re-wrote enough of Linux in golang to be usable, and the overhead was something like 5-15% slower than C. If the goal is Rust everywhere, contribute to Redox. They are further along that road.
  • bluGill 11mo ago
    There needs to be a limit for each project. Debian is a large project so it needs to have more options than smaller projects. Rust is getting popular enough it is reasonable for Debian to say it is an approved option. Note that I'm not saying Debian should, I'm saying it is reasonable that they would. I am not a Debian maintainer and so I should not have an opinion on what tools they use, only that adding Rust isn't unreasonable. It may be reasonable to take away a different tool to get Rust in - again this is something I should not have an opinion on but Debian maintainers should.
  • chrsw 11mo ago
    Linux gave up the fight against complexity a couple of decades ago.
  • doubletwoyou 11mo ago
    Unfortunately, the world is a complicated place and each one of these languages have their own benefits and tradeoffs that suit themselves to one particular language or another (ask an ML scientist to switch to raw C), leading to all of these languages having a valid place in the pantheon of softwares (except maybe for js). Since debian is a pragmatic OS, it needs to adapt to solve for the real problem of being generally usable, and thus supporting all of these languages. Rewriting Everything in one language would be a massive pain and likely a massive waste of time and supporting an OS with less reputation and stable footing like Redox would almost if not more counterproductive as rewriting everything in debian from scratch (it’s a bit hyperbolic to state the goal is to Rewrite Everything in rust), so supporting the gradual replacement of some mission critical components like the apt parser or whatever they’re talking about is likely more realistic. Although an OS definitely shouldn’t “move fast and break things” (especially not one like Debian) I don’t think it’s too ridiculous to drop support for architectures that can’t support a language that was released almost a decade ago. Having a proven language (I think it’s safe to say rust is proven by now, right?) that is much less prone to self-combustion on modification than C, yet maintains a directly compiled nature as well as being to interface relatively well with normal C libraries in some standard applications is a pretty good value-deal proposition in my opinion.
• Surac 11mo ago
  I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready
  • viraptor 11mo ago
    https://github.com/avr-rust https://github.com/avr-rust https://github.com/esp-rs https://github.com/esp-rs https://github.com/rust-embedded/cortex-m https://github.com/rust-embedded/cortex-m Even the embedded world is slowly changing.
  • MangoToupe 11mo ago
    > but as long as the real money is made in c it is not ready People selling slop does not imply much about anything other than the people making the slop
  • the__alchemist 11mo ago
    Rust slaps on embedded too; I think that's one of its core competencies. But you have to do a lot of leg work for each piece of hardware because manufacturer support isn't there, and the OSS libs are usually not great. If your requirement is "Use only the most popular language in this domain", that's fine, but there's no point in evaluating or discussing other languages if so; the outcome is predetermined. I think the linked requirement, the hype you see, and rust's own material is misleading: It's not a memory-safety one-trick lang; it's a nice overall lang and tool set.
    • deleted 11mo ago
      [deleted]
    • lpribis 11mo ago
      The unfortunate reality is that you must write almost all of your drivers from scratch if you want to rust in embedded. There is no OEM driver support, and as you said the open source drivers are all crap and written for arduino-level hobby projects. Lack of drivers is prohibitive if your are a small/medium team or are using a lot of complicated peripherals or SoC. Compare to C where any MCU or embedded SoC or moderately complex peripheral normally comes with C driver code.
• deleted 11mo ago
  [deleted]
• marsven_422 11mo ago
  [dead]
• superkuh 11mo ago
  Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, will NOT be able to compile software written for it's constantly moving bleeding edge. This is an anti-user move to ease developer experience. Very par for the course for modern software.
  • andrepd 11mo ago
    rustc stable is continually updated yes. But surely any given release of debian targets a specific version of the toolchain. What's the issue?
  • onli 11mo ago
    I wouldn't see it that way. First, Debian is not a distro where users have to compile their software. The packages contain binaries, the compilation is already done. The instability of Rust would not affect users in any way. And second, as a developer, I never had a more unpleasant language to work with than Rust. The borrow checker back then was abysmal. Rust is not about developer happiness - Ruby is - but its memory safety makes it a useful option in specific situation. But you can be sure that many developers will avoid it like a plague - and together with the breakage and long compile times that's probably why moves like the one dictated here are so controversial.
    • brainwad 11mo ago
      > The instability of Rust would not affect users in any way. Sure it would. Suppose a rust-based package has a security bug. Upstream has fixed it, but that fix depends on some new rust language feature that the frozen version of rust in Debian doesn't have yet.
      • onli 11mo ago
        Then the responsible Debian maintainer would backport that fix, as they have done in other languages for decades. Really, that's not user facing. It's a possible hassle for the maintainers and developers, which might be bad enough, but not a problem for users.
• lambdaone 11mo ago
  It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dropped for pragmatic reasons, so can these architectures. If people really, really want to preserve these architectures as ongoing platforms for the future, they need to step up and create a backend for the Rust toolchain that supports them.
  • Galanwe 11mo ago
    [flagged]
    • nixosbestos 11mo ago
      > it's factually just better, am I right? so cool to see people getting it!
    • metrix 11mo ago
      While I get your view, I think examples would help to move the conversation along in a more constructive manner
  • astockwell 11mo ago
    Would this logically extend to also include C-reliant languages like Python and Ruby (the latter being mostly a grammar underpinned by C) as technical debt also?
    • gpm 11mo ago
      Not really. All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs. There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.
• amelius 11mo ago
  Can we please also have the hard requirement that code should run without warnings under Valgrind? Because that saves a lot of headaches down the line.
  • krater23 11mo ago
    Would be good for memory safety and wouldn't need a rewrite of all software in a hyped language. No, we shouldn't do that ;)
    • speedgoose 11mo ago
      Motivated people seem to prefer rewriting using a 13 years old programming language. Crazy.
  • julian-klode 11mo ago
    It's certainly what we aim for in APT. We do have an overwrite of course, since we need to copy uninitiated data around: The cache file is allocated as a whole and written at the end, but not all parts of it are used, but it triggers stuff. Don't want to introduce complex code to only copy the parts that are actually reachable would be silly and introduce bugs. But keep in mind valgrind is super buggy and we spend quite a bunch of time working around valgrind false positives (outside of amd64)
    • paulf38 11mo ago
      TBH most “false positives” that I investigate are wishful thinking or the result of ignorance of what is really happening. It looks like you are using Debian. That probably doesn’t help. Here is a typical Debian “bug” report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778 10 years old. It never was a false positive. It was fixed a good few years ago. The fix did not involve suppressing the error. Valgrind does need a lot of work, especially for missing CPU features and for Darwin. I’m not aware of many memcheck bugs that aren’t relatively obscure corner cases. If you have encountered bugs please report them to https://bugs.kde.org https://bugs.kde.org.
• egorfine 11mo ago
  I'm happy for all developers programming in their favorite programming languages. Programming for over 30 years I have seen entire ecosystems come and go. What I don't get is the burning need for Rust developers to insult others. Kind of the same vibes that we get from systemd folks and LP. Does it mean they have psychological issues and deep down in their heart they know they need to compensate? I remember C vs Pascal flame back in the day but that wasn't serious. Like, at all. C/C++ developers today don't have any need to prove anything to anyone. It would be weird for a C developer to walk around and insult Rust devs, but the opposite is prevalent somehow.
  • bgwalter 11mo ago
    Rust developers have corporate backing and therefore feel superior even though the language is an ugly OCaml knockoff.
    • krater23 11mo ago
      They have the backing to doing the right thing, because their language is memory safe and this everytime means absolutely secure. Irony off.
      • jonathanstrange 11mo ago
        IMHO, Rust is proof that many programmers prefer over-engineering and unnecessary complexity with obtuse syntax over sound language design. My personal theory is that they subconsciously like to keep their craft esoteric and "magic." The importance of readability, simplicity, and KISS just isn't taught enough nowadays.
  • deleted 11mo ago
    [deleted]
  • jamincan 11mo ago
    Who is insulting others and where?
• s20n 11mo ago
  > This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem. By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ https://sequoia-pgp.org/ for signature verification? I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.
  • stackghost 11mo ago
    What are the remaining use cases for GnuPG that aren't done better by specialized tools?
  • Valodim 11mo ago
    Sequoia-PGP is 8 years old at this point, their 1.0 happened half a decade ago. Meanwhile, GnuPG is well regarded for its code maturity. But it is a C codebase with nearly no tests, no CI pipeline(!!), an architecture that is basically a statemachine with side effects, and over 200 flags. In my experience, only people who haven't experienced the codebase speak positively of it.
    • julian-klode 11mo ago
      It's rather that GnuPG is ill-regarded for its code immaturity tbh. You don't even need to read the code base, just try to use it in a script: It exits 0 when the verification failed, it exits 1 when it passed, and you have to ignore it all and parse the output of the status fd to find the truth. It provides options to enforce various algorithmic constraints but they only work in some modes and are silently ignored in others.
    • bgwalter 11mo ago
      GnuPG has protected Snowden and he speaks positively of it. Does Sequoia-PGP have similar credentials and who funds it?
  • fastball 11mo ago
    Or did Rust just raise its Series A?
• BobBagwill 11mo ago
  I think anyone who objects to Rust in userland as part of the system should also object to Perl, Python, Ruby, etc. What would really be scary would be a distro that won't even boot unless a variety of LLM's are installed. Boo!
• bgwalter 11mo ago
  [flagged]
  • jeroenhd 11mo ago
    Where exactly is the arrogance? It seems like a rather plain and simple announcement to me.
• pizlonator 11mo ago
  They’d be better off just compiling the package manager with Fil-C No changes required. Bringing up the fil-C toolchain on weird ports is probably less work than bringing up the Rust toolchain
  • bgwalter 11mo ago
    I agree with this. Fil-C is really impressive and Rust can panic, too (if panics/aborts are a concern).
  • julian-klode 11mo ago
    Fil-C is amazing but is much more problematic than Rust at this point since it only supports amd64 at this time and is maintained by a single genius. It also doesn't help you to attract new contributors. With the changes we made over in Ubuntu to switch to rust-coreutils and sudo-rs, we have seen an incredible uptake in community contributions amongst other things, and it's very interesting to me to try to push APT more into the community space. At this time, most of the work on APT is spent by me staying awake late, or during weekends and my 2 week Christmas break, the second largest chunk is the work I do during working hours but that's less cool and exciting stuff :D Adding Rust into APT is one aspect; the other, possibly even more pressing need is rewriting all the APT documentation. Currently the APT manual pages are split into apt-get and apt-cache and so on, with a summary in apt(8) - we should split them across apt install(8), apt upgrade (8) and so on. At the same time, DocBook XML is not very attractive to contributors and switching to reStructuredText with Sphinx hopefully attracts more people to contribute to it.
    • pizlonator 11mo ago
      > since it only supports amd64 at this time and is maintained by a single genius. That's easily fixable. > It also doesn't help you to attract new contributors. I don't understand this point.
      • julian-klode 11mo ago
        > > since it only supports amd64 at this time and is maintained by a single genius. > That's easily fixable. as easily as fixing Rust to work on the remaining 4 architectures? > > It also doesn't help you to attract new contributors. > I don't understand this point. C++ doesn't attract a lot of developers, Rust attracts many more. I want more community, particularly _young_ community. I don't wanna work on this alone all the time :D
• thegrim33 11mo ago
  [flagged]
  • kungito 11mo ago
    What if the person promising the first thing is not the person doing the second thing?
  • __s 11mo ago
    can you link what you're referring to? As I understand, this announcement is about Debian tooling, & you're referencing Linux kernel development discussions
• wolvesechoes 11mo ago
  [flagged]
• StopDisinfo910 11mo ago
  Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.
  • scott_w 11mo ago
    How has a language specification and multiple viable compilers helped C developers write security-critical code?
    • StopDisinfo910 11mo ago
      Considering the number of provers and statistical analysers and given C is the only mainstream language with a formally verified compiler, I would say fairly well thank you. Honestly, I am not even opposed to Rust. It has cool ideas. I do think it should care a lot more about being portable and properly defined and should have done so a lot earlier and I do deeply disagree with the opinion of some core team members that specification is meaningless. C obviously always was a questionable choice for a tool like apt but Rust seems even worse to me. Apt has absolutely no need to be written in a low level language. At least you could argue that C was chosen because it’s portable but I don’t see what Rust has going for it.
      • scott_w 11mo ago
        All those things didn’t stop Heartbleed or numerous other CVEs from happening, though, did it?
      • krzyk 11mo ago
        Doesn't Java have also a formally verified compiler?
  • hypeatei 11mo ago
    Ferrous Systems donated their language specification ("Ferrocene") to the Rust foundation[0] who is working on integrating it but that takes time, obviously. 0: https://rustfoundation.org/media/ferrous-systems-donates-ferrocene-language-specification-to-rust-project/ https://rustfoundation.org/media/ferrous-systems-donates-fer...
• bgwalter 11mo ago
  [flagged]
  • vhantz 11mo ago
    Is Debian linked to Canonical? Isn't tat Ubuntu?
    • sesm 11mo ago
      Ubuntu is built on top of Debian
      • vhantz 11mo ago
        Sure. But Ubuntu and Debian are distributed by different organizations. Canonical does not distribute Debian.
• j16sdiz 11mo ago
  Never tried to port LLVM. Is 6 months a reasonable timeframe to bring LLVM to a new architecture to production quality?
  • rayiner 11mo ago
    Can you use Rust without LLVM by using the Cranelift backend?
    • j16sdiz 11mo ago
      I meant, that email literally ask the fellow developer to either finish the Rust port or sunset the debian port in 6 months. I am asking if the former option is a practical one
      • jeroenhd 11mo ago
        I believe m68k already has a working Rust compiler of sorts, though it's not part of the default Rust chain. I think shaping that fork into something that will let it run and compile like normal is feasible. For other architectures currently unsupported by Rust, I doubt it'll happen. The CPU architectures themselves are long dead and often only used for industrial applications, so the probability of hobbyists getting their hands on them is pretty slim. People still using these old architectures for anything but enthusiast hacking will probably not be using Debian Trixie, and if they do, they can probably find a workaround. It's not like the .deb format itself is changing, so old versions of apt and dpkg will keep working for quite a while.
        • j16sdiz 11mo ago
          In that case, the "6 months" deadline for non-m64k is just a false option. I would consider that a passive-aggressive or an insult
          • jeroenhd 11mo ago
            I'm sure if any of the large corporations depending on legacy hardware would get together and pay people to make the necessary forks, 6 months would be feasible. Practically, they won't, though. I see the deadline more as a "expect breakages in weird unofficial Debian downstreams that were never supported in the first place" or "ask your weird Debian downstream maintainer if this is going to cause problems now". It's not that Debian is banning unofficial downstreams or semi-proprietary forks, but it's not going to let itself be limited by them either. And who knows, maybe there are weird Debian downstreams that I don't know of that do have a working Rust compiler. Projects like Raspbian are probably already set but Debian forks for specific boards may need to tweak a few compiler settings to make compilers emit the right instructions for their ARM/MIPS CPUs to work. I only find the message passive-aggressive or insulting if you're of the opinion you're entitled to Debian never releasing software that doesn't work on the Commodore64.
• rayiner 11mo ago
  Love Julian's email style. Polite, but firm and decisive.
• cozzyd 11mo ago
  His much bigger will this make an embedded Linux Debian image?
  • perlgeek 11mo ago
    Probably not much larger at all, because the image doesn't need to contain Rust toolchain. I don't know if the rust compiler produces bigger binaries, but for a single program, it'll not make a big difference.
• parliament32 11mo ago
  It makes me uncomfortable that this mandate is coming from a Canonical employee. After all, if this switch was a good idea on merit alone, it would happen organically without requiring this kind of combative communication. What's the long-term play for Canonical here?
  • gpm 11mo ago
    It's hard to imagine their is some malicious financial incentive to choosing a different language to write the package manager with... The obvious potential motivations are things like making a more reliable product, or making their employees more productive by giving them access to modern tools... I guess I could imagine preparing for some sort of compliance/legal/regulatory battle where it's important to move towards memory safe tooling but even there I rather imagine that microsoft is better placed to say that they are and any move on canonical's part would be defensive.
  • simonw 11mo ago
    "What's the long-term play for Canonical here?" Presumably it's rewriting critical parsing code in APT to a memory-safe language.
  • Denvercoder9 11mo ago
    Apt has just 3 listed maintainers, and judging by the git history this guy does 90% of the work. Him making the decision _is_ it happening organically. Open source fundamentally is a do-ocracy (it's in literally all of the licenses). Those who do, decide; and more and more often those who do are just one or two people for a tool used by millions.
  • sprash 11mo ago
    The long term play is to drive out community participation and bring in corporate control in the apt/Debian ecosystem.
• hnthrowaway0315 11mo ago
  I don't care whether kernel developers want to use C or Rush or whatever. I judge the quality by using it in production. If it works well then I don't care how they are built.
  • ajkjk 11mo ago
    How can you judge the security qualities of software by using it in production? You're surely not using it in the way someone looking for exploits would use it. Or I guess if you interpret this as a societal scale: we've collectively used C in production a lot, and look at all the security problems. Judgment completed. Quality is low.
    • hnthrowaway0315 11mo ago
      I'm pretty sure many other companies are going to use it in production before mine does. I'll just ask around...
• ok123456 11mo ago
  [flagged]
• threemux 11mo ago
  In the end, only NetBSD will be standing in the breach after anything not x64 or ARMv8+ is declared "retro computing".
• teh64 11mo ago
  Interesting how a person's opinion can change: https://news.ycombinator.com/item?id=27594688 https://news.ycombinator.com/item?id=27594688
  • cbmuser 11mo ago
    I assume it was a management decision to adopt Rust in APT similar to the decision to switch to the Rust version of coreutils.
    • julian-klode 11mo ago
      Let me assure you it was my own decision. The final paragraph is my paraphrasing of a fellow Debian developer and CTTE member's stated opinion.
  • jeroenhd 11mo ago
    If only more people were willing to let their opinions be changed over time like that, rather than clinging onto them.
    • bgwalter 11mo ago
      If only a reason were given. This is the original: > Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update. What has changed? Why is 130 packages for a crypto application acceptable?
      • bonzini 11mo ago
        Probably because 120 (*) have been added in the intervening 4 years. (*) random number
      • jeroenhd 11mo ago
        That's not a Rust problem, that's a sequoia problem. As for why, probably the same reason the dependency tree for gnupg (generate with `debtree -R -b gnupg` but grepping out all the gcc/mingw dependencies) looks like this: https://static.jeroenhd.nl/hn/gnupg.svg https://static.jeroenhd.nl/hn/gnupg.svg There's probably a good reason why I need libjpeg62, libusb-1.0-0-dev, and libgmp3 to compile gnupg, though they're hidden away from the usual developer docs in the form of transitive dependencies; complex software just tends to include external dependencies rather than reinventing the wheel.
• throwaway2037 11mo ago
  The follow-up is solid gold: > I find this particular wording rather unpleasant and very unusual to what I'm used to from Debian in the past. I have to admit that I'm a bit disappointed that such a confrontational approach has been chosen. Ref: https://lists.debian.org/debian-devel/2025/10/msg00286.html https://lists.debian.org/debian-devel/2025/10/msg00286.html
  • octoberfranklin 11mo ago
    Definitely the adult in the room.
• ugh123 11mo ago
  >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. Loved this statement on the state of modern software using the backbone of C (in linux and elsewhere)
• josefx 11mo ago
  Is this the end of Debian as GNU/Linux? The main Rust toolchain isn't GNU, gccrs is still incomplete and most Rust rewrites of existing GNU libraries and tools use MIT or other non GPL licenses.
  • xbar 11mo ago
    It is hard to see it as anything else.
  • gpm 11mo ago
    The main python and perl toolchains were never maintained by GNU either. Python has never been distributed under a GPL license. I'm not 100% sure of the licensing history of perl but I think it's always been available under a non-GPL license (as well as being under a GPL license - at least recently - not sure if that was always the case). This doesn't seem like a noteworthy change to the degree to which GNU/Linux is an accurate name... though there are lots of things I'd put more importance on than GNU in describing debian (systemd, for instance). Edit: Looks like Perl 1.0 was under the following non-commercial license, so definitely not always GPL though that now leaves the question of licensing when debian adopted it, if you really care. > You may copy the perl kit in whole or in part as long as you don't try to make money off it, or pretend that you wrote it. https://github.com/AnaTofuZ/Perl-1.0/blob/master/README.orig https://github.com/AnaTofuZ/Perl-1.0/blob/master/README.orig
  • rcxdude 11mo ago
    GNU/Linux as a term was kind of a credit-grab by GNU anyway. They never were entirely responsible for the userspace. But, there are now a lot more replacements for GNU's contributions under non-copyleft licenses, for sure.
• larusso 11mo ago
  I really like to write programs in rust. But my stance has changed a bit over the years ever since other languages caught up a bit. On top of that I’m very skeptical if the rewrite of an ancient tool brings more less security. I don’t know the apt source code or how it actually works behind the cli interface so I leave this judgement to the pros. But there seems to be a very strong move to rewrite all core systems in rust. My issue with that is the fact that these tools don’t even invent anything new. Or change / improve the status co. I understand that it’s hard to introduce a new system without breaking other stuff. But our systems are still based on decisions from the telegraph age. Layers on top of layers on top of layers.
  • jagged-chisel 11mo ago
    People have to learn on some project. Why not something that’s simple to test against? You know what it should do, so let’s rewrite it! Whether the rewrite should be adopted to replace the original is certainly a big discussion. But simply writing a replacement isn’t really worth complaining about.
  • TuxSH 11mo ago
    > Or change / improve the status [quo] uutils/coreutils is MIT-licensed and primarily hosted on GitHub (with issues and PRs there) whereas GNU coreutils is GPL-licensed and hosted on gnu.org (with mailing lists). EDIT: I'm not expressing a personal opinion, just stating how things are. The license change may indeed be of interest to some companies.
    • collinfunk 11mo ago
      2 GNU coreutils maintainers, including myself, monitor the issues and PRs on a GitHub mirror that we have [1]. Generally the mailing list is preferred though, since more people follow it. [1] https://github.com/coreutils/coreutils https://github.com/coreutils/coreutils
    • cardanome 11mo ago
      So a change to the worse. The GPL protects the freedom of the users while MIT-licensed software can be easily rug-pulled or be co-opted by the big tech monopolists. Using GitHub is unacceptable as it is banning many countries from using it. You are excluding devs around the world from contributing. Plus it is owned by Microsoft. So we replaced a strong copyleft license and a solid decentralized workflow with a centralized repo that depends on the whims of Microsoft and the US government and that is somehow a good thing?
• t43562 11mo ago
  I've been trying to build a debian package recently. I didn't have any crashes but I couldn't work out how to do it especially with the unbelievably contradictory and confusing documentation. I'm so glad I mainly use makepkg on Artix which is MUCH easier. I struggle to believe that this is really about a call to improve quality when there seem to be some other huge juicy targets.
  • gspr 11mo ago
    Are you sure you're not conflating documentation with random people's writings on the web? Because that there seems to be a helluva lot of cargo culting on this topic.
    • t43562 11mo ago
      When the primary documentation is of no use one looks for anything else that can possibly help and a lot of that is out of date.
      • gspr 11mo ago
        What's wrong with the primary documentation?
        • t43562 11mo ago
          I was doing this months ago and have forgotten every twisty road I went down but I wanted to produce a binary package for a particular version of Ubuntu (and or Debian) and put it in a PPA so that people could use my code easily. It seemed like the rules file could be anything and I wouldn't have to implement a lot of targets that are either irrelevant or hard to understand the purpose of. So I used a script. Mistake - makefiles now seem to be the thing. I struggled over how to layout the directories in my GIT repo. The fact that I want to build from the git repo is another layer of confusion - as opposed to building from a tarfile. I'm making something unstable for other developers right now, rather than a stable releasable item. The next bit of extreme confusion is .... where should my package's install target put the binary plugins I built. I'm not going to try to go back and check over this in detail but as far as I remember the docs were very unspecific about that as if it could be anywhere and different user docs on the net seemed to show different things. I got to the point where I could appear to build the thing on my machine but that's not good enough - the PPA has to be able to do it and then you've got to upload, wait and hope the log explains what's wrong well enough. I tried looking at other packages - I'm building plugins for GNU make so I tried that - but it was using the build from tar approach (IIRC) and was way overcomplicated for my very simple package which is just a few .so files in a directory. It took me a couple of weeks of messing around with every possible option to get this far and I just ran out of energy and time. I am not a beginner at programming - only at packaging - so IMO there is a great deal that could be done for the user experience. Don't get me wrong - I'm not picking on .deb. RPM is another incredibly horrible packaging system where every tiny mistake can force a long long long rebuild. They're obviously complicated because they're trying to offer a lot and e.g. Artix doesn't use selinux so there's one misery avoided straight away but it has a consequence. IMO the core docs just don't prevent any of this confusion. They seem like a reference for people who already know what they're doing and enough tutorial for a very specific simple case that wasn't mine. People wouldn't bother to write their own tutorials if the docs filled the need.
• zenxyzzy 11mo ago
  Rust evangelists are tiresome. It's not gonna fix the tech debt problem, No matter how much rust crack you smoke. Disciplined use of c, with modern tools like valgrind, will give you safe code without having to lobotomize yourself into fighting the borrow checker for everything, even manifestly simple code.
  • paulf38 11mo ago
    It would be nice (speaking as a Valgrind developer) if Valgrind could guarantee safe code. Unfortunately it doesn’t. Firstly, it does not detect all kinds of errors (and indeed no tool does). Secondly, it is unlikely that the test coverage is perfect. Delusional overconfidence that developer “skill” is all that is needed to overcome the many shortcomings of C is not a solution to the problem of guaranteeing security and safety.
    • jstimpfle 11mo ago
      I find it surprising hearing statements like this from a developer of a tool for, well, C programmers mostly I guess? "Skill is all that is needed to prevent bugs and produce bug-free software" is a phrase I've never heard from an actual C programmer, but have heard plenty of times from detractors. The C programmers I know are certainly not deluded or overconfident. They don't even think "their" language is a perfect one, or even a very good one. They just avoid black-and-white thinking. They take a practical approach about memory issues, seeing them more like any other kind of bug. It's a different aesthetics than you would maybe see from many Rust folks. They want to be productive and want to be in control and want to understand what their code does. In turn, they accept that in some cases, bugs (possibly memory bugs) creep in, some of which could go unnoticed for some time. They tend to not see that as a huge issue, at least in general, because an issue that has gone unnoticed (or didn't manifest) is often less of a problem than one that is immediately obvious. (In case of data corruption, it _can_ be a huge issue, and you have to add safeguards to prevent it, and have to be accepting some residual risk). They understand that everything is a trade off and that with experience and practice, good architecture, good tooling etc. you can prevent many bugs early, and detect them early. They have tried many approaches to prevent bugs, including fancy languages and constructs, and have concluded that in many cases, perfect safety is not possible, in particular it's not possible without seriously hurting other requirements, such as productivity. As to valgrind, I can say that it was a bit of a mixed bag for me. It did help me finding bugs a number of times, but I also had to configure it a bit because it was producing a lot of noise for some external libraries (such as libc). I don't really understand the underlying issues.
• taccal 11mo ago
  [dead]
• RustSupremacist 11mo ago
  This is the same maintainer who broke KeePass on Debian and then flipped off everyone in the thread. Someone needs to pull him aside and let him know the world does not revolve around him and the problems he chooses to manufacture to justify his paycheck. https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
• westurner 11mo ago
  From the mailing list on this: https://lists.debian.org/debian-devel/2025/10/msg00288.html https://lists.debian.org/debian-devel/2025/10/msg00288.html : > Be careful. Rust does not support some platforms well.[0] ANything > that is not Tier 1 is not guaranteed to actually work. And > architectures like m68k and powerpc are Tier 3. > > [0] <https://doc.rust-lang.org/beta/rustc/platform-support.html>. [ The rustc book > Platform Support: https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html ] [ The rustic book > Target Tier Policy: https://doc.rust-lang.org/beta/rustc/target-tier-policy.html#target-tier-policy https://doc.rust-lang.org/beta/rustc/target-tier-policy.html... ] Thank you for your message. 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). Create a plan to add support for {alpha, hppa, m68k, and sh4,} targets to the Rust compiler - 2.5pro: "Rust Compiler Target Porting Plan" https://gemini.google.com/share/b36065507d9d https://gemini.google.com/share/b36065507d9d : > [ rustc_codegen_gcc, libcore atomics for each target (m68k does not have support for 64-bit atomics and will need patching to libgcc helper functions), ..., libc, liballoc and libstd (fix std::thread, std::fs, std::net, std::sync), and then compiletest will find thousands of bugs ] So, CI build hours on those actual but first emulated ISAs? "Google porting all internal workloads to ARM, with help from GenAI" (2025) https://news.ycombinator.com/item?id=45691519 https://news.ycombinator.com/item?id=45691519 "AI-Driven Software Porting to RISC-V" (2025) https://news.ycombinator.com/item?id=45315314 https://news.ycombinator.com/item?id=45315314 "The Unreasonable Effectiveness of Fuzzing for Porting Programs" (2025) https://news.ycombinator.com/item?id=44311241 https://news.ycombinator.com/item?id=44311241 : > A simple strategy of having LLMs write fuzz tests and build up a port in topological order seems effective at automating porting from C to Rust.
• nialv7 11mo ago
  Didn't they call Rust software "unpackageable" just a couple of months ago? IIRC they were talking about bcachefs-tools.
  • steveklabnik 11mo ago
    Debian has packaged rustc and Rust based programs for the better part of a decade now.
    • syahlaaa 11mo ago
      [flagged]
    • nialv7 11mo ago
      It was posted on Hacker News... https://news.ycombinator.com/item?id=41407768 https://news.ycombinator.com/item?id=41407768 Author quite literally said bcachefs-tools "is impossible to maintain in Debian stable", and the reason cited was Rust.
      • steveklabnik 11mo ago
        One person said one program is hard to package, sure. That doesn’t change that both rustc and programs that use rust have been packaged for a very, very long time.
• richard_todd 11mo ago
  I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting, as is always evident by the complaints it causes. I love projects like Redox that try to do their own thing... why doesn't the rust community rally around projects like that and turn them into cve-free masterpieces that people will want to use?
  • jeffparsons 11mo ago
    This email is from a Debian maintainer, about Debian introducing a new hard dependency on Rust. It's not some random Rust advocate telling Debian folks that they should use Rust against their will. Yes there are absolutely some obnoxious "you should rewrite this in Rust" folks out there, but this is not a case of that.
    • richard_todd 11mo ago
      There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to". And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
      • pornel 11mo ago
        You seem to think of "rust enthusiasts" as some organized group with a goal of writing Rust for the sake of it. Rust is long past such extremely early adopter phase. What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developers everywhere adopting Rust as a tool to get their job done, not to play language wars.
• hacker_homie 11mo ago
  I guess this is fine if you are using the rust standard library, I just don't want to see cargo pulling 500 packages to build this deb parsing code.
• zahlman 11mo ago
  > 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. ... This is Debian we're talking about here? ... What distros are recommended for those who intend to continue trying to squeeze utility out of "retro computing devices"? ... And what sort of minimum specifications are we talking about, here?
• Havoc 11mo ago
  Time for the scheduled monthly rust drama I see. More seriously I think Linux in general could benefit from a bit more pruning legacy stuff and embracing new so I count this as a plus
• shmerl 11mo ago
  Sounds like business as usual.
• teddyh 11mo ago
  IMHO, Rust is not mature until it decides on a stable ABI, and starts being able to use non-static linking, and therefore able to produce dynamically linked binaries.
• rpcope1 11mo ago
  One major point of heartburn with Rust is that it comparatively lacks the diversity of ISA targets that C broadly does. I know some of this is because C is both relatively simple to write a basic compiler for that more or less just works (in comparison to something crazy like C++), and that's it's been around for a long time, but why isn't there more of a push to add at least all of the supported Debian ISAs to the Rust compiler?
  • klodolph 11mo ago
    Most people don't write a basic compiler for C either, "relatively simple" or no. Most people would rather add a new target to an existing compiler, which is much easier. It's also "relatively easy" to add a new backend to Rust. There's a policy document for Rust here: https://doc.rust-lang.org/rustc/target-tier-policy.html https://doc.rust-lang.org/rustc/target-tier-policy.html There are a lot of things that can go wrong. You want to be able to test. Being able to test requires that someone has test hardware.
  • Measter 11mo ago
    There's no push to add Debian's officially supported platforms to Rust because Rust already supports those platforms.
• drnick1 11mo ago
  My main objection to Rust is how ugly it looks. Why did they have to change things such as how types and functions are defined? I really hate keywords such as def, fn, and other "explicit" function declarations. Also all the :: and <> from C++. Language-wise Java and C# did a much better job at introducing the features they needed without breaking the readability and familiarity of C.
  • qiu3344 11mo ago
    The "spiral" type declaration syntax from C is hard to parse, both for humans and machines. That's probably why even C++ is moving away from it: C modern C++ "int foo[5]" -> "array<int,5> foo" It's easy to criticize simple examples like the one above, since the C++ (or Rust) version is longer than the C declaration, but consider something like this: char *(*(**foo[][8])())[]; and the idiomatic Rust equivalent: let foo: Vec<[Option<fn() -> Vec<String>>; 8]> = Vec::new(); The later can be parsed quite trivially by descending into the type declaration. It's also visible at a glimpse, that the top-level type is a Vec and you can also easily spot the lambda and it's signature. Another ergonomic aspect of the Rust syntax is that you can easily copy the raw type, without the variable name: Vec<[Option<fn() -> Vec<String>>; 8]> While the standalone C type looks like this: char *(*(**[][8])())[] which is quite a mess to untangle ;) Also, I think C# is generally closer to Rust than to C when it comes to the type syntax. A rough equivalent to the previous example would be: var foo = new List<Func<List<string>>?[]>(); I can't deny that "?" is more ergonomic than Rust's "Option<T>", but C# has also a way less expressive type system than Rust or C++, so pick your poison.
    • eYrKEC2 11mo ago
      For C, once I learned that types are best read right-to-left, they became much more scrutable. int[] foo | | | | | foo | is an array of ints I still prefer Rust types though..
• offmycloud 11mo ago
  How does this impact reproducible builds in Debian? Does Rust have a good bootstrap story now?
• lesser-shadow 11mo ago
  [dead]