4 ms·

Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opport

Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change. It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable. There's no clear cost-benefit analysis done for this change. Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse. I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community.

foota 11mo ago
*It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious." Imo this is true for going from one to a handful, but less true when going from a handful to more. Afaict there are 6 official ports and 12 unofficial ports (from https://www.debian.org/ports/ https://www.debian.org/ports/).
- wtallis 11mo ago
  It really comes down to which architectures you're porting to. The two biggest issues are big endian vs little endian, and memory consistency models. Little endian is the clear winner for actively-developed architectures, but there are still plenty of vintage big endian architectures to target, and it looks like IBM mainframes at least are still exclusively big endian. For memory consistency, Alpha historically had value as the weakest and most likely to expose bugs. But nobody really wants to implement hardware like that anymore, almost everything falls somewhere on the spectrum of behavior bounded by x86 (strict) and Arm (weaker), and newer languages (eg. C++ 11) mean newer code can be explicit about its expectations rather than ambiguous or implicit.
Aurornis 11mo ago
> This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable. I’m Normally I’d agree, but the ports in question are really quite old and obscure. I don’t think anything would have changed with an even longer timeline. I think the best move would have been to announce deprecation of those ports separately. As it was announced, people who will never be impacted by their deprecation are upset because the deprecation was tied to something else (Rust) that is a hot topic. If the deprecation of those ports was announced separately I doubt it would have even been news. Instead we’ve got this situation where people are angry that Rust took something away from someone.
- steveklabnik 11mo ago
  Those ports were never official, and so aren't being deprecated. Nothing changes about Debian's support policies with this change. EDIT: okay so I was slightly too strong: some of them were official as of 2011, but haven't been since then. The main point that this isn't deprecating any supported ports is still accurate.
  - Aurornis 11mo ago
    That’s helpful info, but I don’t think it will change any of the minds that are angry about what they see as Rust taking something away from someone. It’s the way the two actions were linked that caused the controversy.
locknitpicker 11mo ago
> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. This right here. As a side-note, I was reading one of Cloudflare's docs on how it implemented its firewall rules, and it's so utterly disappointing how the document stops being informative suddenly start to reads like a parody of the whole cargo cult around Rust. Rust this, Rust that, and I was there trying to read up on how Cloudflare actually supports firewall rules. The way they focus on a specific and frankly irrelevant implementation detail conveys the idea things are ran by amateurs that are charmed by a shiny toy.
travisgriggs 11mo ago
> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. Thanks for this. I know intellectually, that there are sane/pragmatic people who appreciate Rust. But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel special”. So it helps when the reasonable signal breaks through the noisy minority.
- vablings 11mo ago
  >I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod. for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly and performance will probably exceed the original implementation in some cases since concurrency is a cake-walk. The whole re-write it in rust largely stemmed from the idea that if you have a program in C and a program in Rust then the program in rust is "automatically" better which is often the case. The exception is very large battle tested projects with custom tooling in place to ensure the issues that make C/C++ a nightmare are somewhat reduced. Rust ships with the borrow checker by default meaning logically its like for like. In the real world it is not always the case there are still plenty of opportunity for straight up logic bugs and crashes (See cloudflare saga) that are completely just due to bad programming practices. Rust is the nail and the hammer, but you can still hit your finger if you don't know how to swing it properly FYI for the purpose of disclosing bias I am one of the few "rust first" developers. I learned the language in 2021, and it was the first "real" programming language I learned how to use effectively. Any attempts I have had to dive into other languages have been short lived and incredibly frustrating because rust is a first-class experience in how to make a systems programming language
  - influx 11mo ago
    It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.
kevin_thibedeau 11mo ago
> Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for This will be an impediment for new architectures in the future. Instead of just "builds with gcc" we would need to wait for Rust support.
- crote 11mo ago
  > Instead of just "builds with gcc" we would need to wait for Rust support. There's always rustc_codegen_gcc (gcc backend for rustc) and gccrs (Rust frontend for gcc). They are't quite production-ready yet, but there's a decent chance it's good enough for the handful of hobbyists wanting to run the latest applications on historical hardware. As to adding new architectures: it just shifts the task from "write gcc backend" to "write llvm backend". I doubt it'll make much of a difference in practice.
dathinab 11mo ago
> and the author didn't provide them the opportunity to provide feedback on the change. this is wrong, the author wrote a mail about _intended_ changes _1/2 year_ before shipping them on the right Debian mailing list. That is _exactly_ how giving people an opportunity to give feedback before doing a change works... Sure, they made it clear they don't want any discussions to be side tracked about a topics about thing Debian doesn't official support. That is not nice, but understandable, I have seen way too much time wasted on discussions being derailed. The only problem here is people overthinking things and/or having issues with very direct language IMHO. > This is breaking support for multiple ports to rewrite some feature for a tiny security benefit It's not braking anything supported. The only thing breaking are unsupported. And are only niche used too. Nearly all projects have very limited capacities and have to draw boundaries, and the most basic boundary is unsupported means unsupported. This doesn't mean you don't keep unsupported use cases in mind/avoid accidentally breaking them, but it means they don't majorly influence your decision. > And doing so on an unacceptably short timeline 1/2 a year for a change which only breaks unsupported things isn't "unacceptably short", it's actually pretty long. If this weren't OSS you could be happy about one month and most likely less. People complain about how little resources OSS projects have, but the scary truth is most commercial projects have even less resource and must ship at a dead line. Hence why it's very common for them to be far worse when it comes to code quality, technical dept, not correctly handled niche error cases etc. > to every architecture they release for Rust toolchain has support for every architecture _they_ release for, it breaks architectures niche unofficial 3rd party projects support. Which is sad, sure, but unsupported is in the end unsupported. > cost-benefit analysis done for this change. Who says it wasn't done at all. People have done so over and over on the internet for all kind of Linux distributions. But either way, you wouldn't include that in a mail announcing an intend for change (as you don't want discussions to be side tracked). Also benefits are pretty clear: - using Sequoia for PGP seems to be the main driving force behind this decision, this projects exists because of repeating running into issues (including security issues) with the existing PGP tooling. It happens to use rust, but if there where no rust it still would exist. Just using a different language. - some file format parsing is in a pretty bad state to a point you most likely will rewrite it to fix it/make it robust. When anyway doing so it using rust if preferable. - and long term: Due to the clear, proven(1), benefits of using rust for _new_ project/code increasingly more use it, by not "allowing" rust to be required Debian bars itself form using any such project (like e.g. Sequoia which seems to be the main driver behind this change) > this "rewrite it in rust" evangilism which isn't part of this discussion at all, the main driving part seems to be to use Sequoia, not because Sequoia is in rust but because Sequoia is very well made and well tested. Similar Sequoia isn't a "lets re-write everything in rust project" but a "state of PGP tooling" is so painful for certain use cases (not all) in ways you can't fix by trying to contribute upstream that some people needed a new tooling, and rust happened to be the choice for implementing that.
crote 11mo ago
> It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. The problem is that those ports aren't supported and see basically zero use. Without continuous maintainer effort to keep software running on those platforms, subtle platform-specific bugs will creep in. Sometimes it's the application's fault, but just as often the blame will lie with the port itself. The side-effect of ports being unsupported is that build failures or test failures - if they are even run at all - aren't considered blockers. Eventually their failure becomes normal, so their status will just be disregarded as noise: you can't rely on them to pass when your PR is bug-free, so you can't rely on their failure to indicate a genuine issue.
pjmlp 11mo ago
I fully agree, and in what concerns command line utility applications I see no benefit of using Rust's borrow checker. At most if a rewrite would happen, it makes much more sense in a compiled language with automatic resource management.
- crote 11mo ago
  Command line utilities often handle not-fully-trusted data, and are often called from something besides an interactive terminal. Take for example git: do you fully trust the content of every repository you clone? Sure, you'll of course compile and run it in a container, but how prepared are you for the possibility of the clone process itself resulting in arbitrary code execution? The same applies to the other side of the git interaction: if you're hosting a git forge, it is basically a certainty that whatever application you use will call out to git behind the scenes. Your git forge is connected to the internet, so anyone can send data to it, so git will be processing attacker-controlled data. There are dozens of similar scenarios involving tools like ffmpeg, gzip, wget, or imagemagick. The main power of command line utilities is their composability: you can't assume it'll only ever be used in isolation with trusted data!
  - pjmlp 11mo ago
    None of that requires a borrow checker. Any memory safe compiled managed language will do.
    - crote 11mo ago
      That's definitely true! Some people might complain about the startup cost of a language like Java, though: there are plenty of scripts around which are calling command-line utilities in a very tight loop. Not every memory-safe language is suitable for every command-line utility.
      - pjmlp 11mo ago
        Java is not the only option, and even then, GraalVM and OpenJ9 exist, long are the days people had to pay for something like Excelsior JET.
eggy 11mo ago
I totally agree. In reality, today, if you want to produce auditable high-integrity, high-assurance, mission-critical software, you should be looking at SPARK/Ada and even F* (fstar). SPARK has legacy real world apps and a great eco system for this type of sofware. F* is being used on embedded and in other realworld apps where formal verification is necessary or highly advantageous. Whether I like Rust or not, should not be the defining factor. AdaCore has a verifed Rust compiler, but the tooling around it does not compare to that around SPARK/Ada. I've heard younger people complain about PLs being verbose, boring, or not their thing, and unless you're a diehard SPARK/Ada person, you probably feel that way about it too. But sometimes the tool doesn't have to be sexy or the latest thing to be the right thing to use. Name one Rust realworld app older than 5 years that is in this category.
- crote 11mo ago
  > Name one Rust realworld app older than 5 years that is in this category. Your "older than 5 years" requirement isn't really fair, is it? Rust itself had its first stable release barely 10 years ago, and mainstream adoption has only started happening in the last 5 years. You'll have trouble finding any "real-world" Rust apps older than 5 years! As to your actual question: The users of Ferrocene[0] would be a good start. It's Rust but certified for ISO 26262 (ASIL D), IEC 61508 (SIL 4) and IEC 62304 - clearly someone is interested in writing mission-critical software in Rust! [0]: https://ferrocene.dev/ https://ferrocene.dev/
  - eggy 11mo ago
    The point was how would you justify choosing Rust based on any real world proof. Maybe it will be ready in a few years, but even then it is far from achieving what you already have in SPARK along with proven legacy. I am very familiar with this, and I still chose SPARK/Ada instead of Rust. SPARK is already certified for all of this. And aerospace, railway, and other high-integrity app industries are already familiar with the output of the SPARK tools, so there's less friction and time in auditing them for certification. Aside from AdaCore, who collaborated with Ferrocene, to get a compiler certified I don't see much traction to change our decision. We are creating show control software for cyber-physical systems with potential dire consequences, so we did a very in-depth study Q1 2025, and Rust came up short.
ForHackernews 11mo ago
> Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse. They already have a Rust toolchain for every system Debian releases for. The only architectures they're arguing about are non-official Debian ports for "Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4)", two of which are so obscure I've never even heard of them and one of the others most famous for powering retro video game systems like Sega Genesis.
oconnor663 11mo ago
> to rewrite some feature for a tiny security benefit For what it's worth, the zero->one introduction of a new language into a big codebase always comes with a lot of build changes, downstream impact, debate, etc. It's good for that first feature to be some relatively trivial thing, so that it doesn't make the changes any bigger than they have to be, and so that it can be delayed or reverted as needed without causing extra trouble. Once everything lands, then you can add whatever bigger features you like without disrupting things. No comment on the rest of the thread...

foota 11mo ago

*It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious." Imo this is true for going from one to a handful, but less true when going from a handful to more. Afaict there are 6 official ports and 12 unofficial ports (from https://www.debian.org/ports/ https://www.debian.org/ports/).

wtallis 11mo ago
It really comes down to which architectures you're porting to. The two biggest issues are big endian vs little endian, and memory consistency models. Little endian is the clear winner for actively-developed architectures, but there are still plenty of vintage big endian architectures to target, and it looks like IBM mainframes at least are still exclusively big endian. For memory consistency, Alpha historically had value as the weakest and most likely to expose bugs. But nobody really wants to implement hardware like that anymore, almost everything falls somewhere on the spectrum of behavior bounded by x86 (strict) and Arm (weaker), and newer languages (eg. C++ 11) mean newer code can be explicit about its expectations rather than ambiguous or implicit.

Aurornis 11mo ago

> This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable. I’m Normally I’d agree, but the ports in question are really quite old and obscure. I don’t think anything would have changed with an even longer timeline. I think the best move would have been to announce deprecation of those ports separately. As it was announced, people who will never be impacted by their deprecation are upset because the deprecation was tied to something else (Rust) that is a hot topic. If the deprecation of those ports was announced separately I doubt it would have even been news. Instead we’ve got this situation where people are angry that Rust took something away from someone.

steveklabnik 11mo ago
Those ports were never official, and so aren't being deprecated. Nothing changes about Debian's support policies with this change. EDIT: okay so I was slightly too strong: some of them were official as of 2011, but haven't been since then. The main point that this isn't deprecating any supported ports is still accurate.
- Aurornis 11mo ago
  That’s helpful info, but I don’t think it will change any of the minds that are angry about what they see as Rust taking something away from someone. It’s the way the two actions were linked that caused the controversy.

locknitpicker 11mo ago

> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. This right here. As a side-note, I was reading one of Cloudflare's docs on how it implemented its firewall rules, and it's so utterly disappointing how the document stops being informative suddenly start to reads like a parody of the whole cargo cult around Rust. Rust this, Rust that, and I was there trying to read up on how Cloudflare actually supports firewall rules. The way they focus on a specific and frankly irrelevant implementation detail conveys the idea things are ran by amateurs that are charmed by a shiny toy.

travisgriggs 11mo ago

> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. Thanks for this. I know intellectually, that there are sane/pragmatic people who appreciate Rust. But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel special”. So it helps when the reasonable signal breaks through the noisy minority.

vablings 11mo ago
>I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod. for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly and performance will probably exceed the original implementation in some cases since concurrency is a cake-walk. The whole re-write it in rust largely stemmed from the idea that if you have a program in C and a program in Rust then the program in rust is "automatically" better which is often the case. The exception is very large battle tested projects with custom tooling in place to ensure the issues that make C/C++ a nightmare are somewhat reduced. Rust ships with the borrow checker by default meaning logically its like for like. In the real world it is not always the case there are still plenty of opportunity for straight up logic bugs and crashes (See cloudflare saga) that are completely just due to bad programming practices. Rust is the nail and the hammer, but you can still hit your finger if you don't know how to swing it properly FYI for the purpose of disclosing bias I am one of the few "rust first" developers. I learned the language in 2021, and it was the first "real" programming language I learned how to use effectively. Any attempts I have had to dive into other languages have been short lived and incredibly frustrating because rust is a first-class experience in how to make a systems programming language
- influx 11mo ago
  It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.

kevin_thibedeau 11mo ago

> Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for This will be an impediment for new architectures in the future. Instead of just "builds with gcc" we would need to wait for Rust support.

crote 11mo ago
> Instead of just "builds with gcc" we would need to wait for Rust support. There's always rustc_codegen_gcc (gcc backend for rustc) and gccrs (Rust frontend for gcc). They are't quite production-ready yet, but there's a decent chance it's good enough for the handful of hobbyists wanting to run the latest applications on historical hardware. As to adding new architectures: it just shifts the task from "write gcc backend" to "write llvm backend". I doubt it'll make much of a difference in practice.

dathinab 11mo ago

> and the author didn't provide them the opportunity to provide feedback on the change. this is wrong, the author wrote a mail about _intended_ changes _1/2 year_ before shipping them on the right Debian mailing list. That is _exactly_ how giving people an opportunity to give feedback before doing a change works... Sure, they made it clear they don't want any discussions to be side tracked about a topics about thing Debian doesn't official support. That is not nice, but understandable, I have seen way too much time wasted on discussions being derailed. The only problem here is people overthinking things and/or having issues with very direct language IMHO. > This is breaking support for multiple ports to rewrite some feature for a tiny security benefit It's not braking anything supported. The only thing breaking are unsupported. And are only niche used too. Nearly all projects have very limited capacities and have to draw boundaries, and the most basic boundary is unsupported means unsupported. This doesn't mean you don't keep unsupported use cases in mind/avoid accidentally breaking them, but it means they don't majorly influence your decision. > And doing so on an unacceptably short timeline 1/2 a year for a change which only breaks unsupported things isn't "unacceptably short", it's actually pretty long. If this weren't OSS you could be happy about one month and most likely less. People complain about how little resources OSS projects have, but the scary truth is most commercial projects have even less resource and must ship at a dead line. Hence why it's very common for them to be far worse when it comes to code quality, technical dept, not correctly handled niche error cases etc. > to every architecture they release for Rust toolchain has support for every architecture _they_ release for, it breaks architectures niche unofficial 3rd party projects support. Which is sad, sure, but unsupported is in the end unsupported. > cost-benefit analysis done for this change. Who says it wasn't done at all. People have done so over and over on the internet for all kind of Linux distributions. But either way, you wouldn't include that in a mail announcing an intend for change (as you don't want discussions to be side tracked). Also benefits are pretty clear: - using Sequoia for PGP seems to be the main driving force behind this decision, this projects exists because of repeating running into issues (including security issues) with the existing PGP tooling. It happens to use rust, but if there where no rust it still would exist. Just using a different language. - some file format parsing is in a pretty bad state to a point you most likely will rewrite it to fix it/make it robust. When anyway doing so it using rust if preferable. - and long term: Due to the clear, proven(1), benefits of using rust for _new_ project/code increasingly more use it, by not "allowing" rust to be required Debian bars itself form using any such project (like e.g. Sequoia which seems to be the main driver behind this change) > this "rewrite it in rust" evangilism which isn't part of this discussion at all, the main driving part seems to be to use Sequoia, not because Sequoia is in rust but because Sequoia is very well made and well tested. Similar Sequoia isn't a "lets re-write everything in rust project" but a "state of PGP tooling" is so painful for certain use cases (not all) in ways you can't fix by trying to contribute upstream that some people needed a new tooling, and rust happened to be the choice for implementing that.

crote 11mo ago

> It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. The problem is that those ports aren't supported and see basically zero use. Without continuous maintainer effort to keep software running on those platforms, subtle platform-specific bugs will creep in. Sometimes it's the application's fault, but just as often the blame will lie with the port itself. The side-effect of ports being unsupported is that build failures or test failures - if they are even run at all - aren't considered blockers. Eventually their failure becomes normal, so their status will just be disregarded as noise: you can't rely on them to pass when your PR is bug-free, so you can't rely on their failure to indicate a genuine issue.

pjmlp 11mo ago

I fully agree, and in what concerns command line utility applications I see no benefit of using Rust's borrow checker. At most if a rewrite would happen, it makes much more sense in a compiled language with automatic resource management.

crote 11mo ago
Command line utilities often handle not-fully-trusted data, and are often called from something besides an interactive terminal. Take for example git: do you fully trust the content of every repository you clone? Sure, you'll of course compile and run it in a container, but how prepared are you for the possibility of the clone process itself resulting in arbitrary code execution? The same applies to the other side of the git interaction: if you're hosting a git forge, it is basically a certainty that whatever application you use will call out to git behind the scenes. Your git forge is connected to the internet, so anyone can send data to it, so git will be processing attacker-controlled data. There are dozens of similar scenarios involving tools like ffmpeg, gzip, wget, or imagemagick. The main power of command line utilities is their composability: you can't assume it'll only ever be used in isolation with trusted data!
- pjmlp 11mo ago
  None of that requires a borrow checker. Any memory safe compiled managed language will do.
  - crote 11mo ago
    That's definitely true! Some people might complain about the startup cost of a language like Java, though: there are plenty of scripts around which are calling command-line utilities in a very tight loop. Not every memory-safe language is suitable for every command-line utility.
    - pjmlp 11mo ago
      Java is not the only option, and even then, GraalVM and OpenJ9 exist, long are the days people had to pay for something like Excelsior JET.

eggy 11mo ago

I totally agree. In reality, today, if you want to produce auditable high-integrity, high-assurance, mission-critical software, you should be looking at SPARK/Ada and even F* (fstar). SPARK has legacy real world apps and a great eco system for this type of sofware. F* is being used on embedded and in other realworld apps where formal verification is necessary or highly advantageous. Whether I like Rust or not, should not be the defining factor. AdaCore has a verifed Rust compiler, but the tooling around it does not compare to that around SPARK/Ada. I've heard younger people complain about PLs being verbose, boring, or not their thing, and unless you're a diehard SPARK/Ada person, you probably feel that way about it too. But sometimes the tool doesn't have to be sexy or the latest thing to be the right thing to use. Name one Rust realworld app older than 5 years that is in this category.

crote 11mo ago
> Name one Rust realworld app older than 5 years that is in this category. Your "older than 5 years" requirement isn't really fair, is it? Rust itself had its first stable release barely 10 years ago, and mainstream adoption has only started happening in the last 5 years. You'll have trouble finding any "real-world" Rust apps older than 5 years! As to your actual question: The users of Ferrocene[0] would be a good start. It's Rust but certified for ISO 26262 (ASIL D), IEC 61508 (SIL 4) and IEC 62304 - clearly someone is interested in writing mission-critical software in Rust! [0]: https://ferrocene.dev/ https://ferrocene.dev/
- eggy 11mo ago
  The point was how would you justify choosing Rust based on any real world proof. Maybe it will be ready in a few years, but even then it is far from achieving what you already have in SPARK along with proven legacy. I am very familiar with this, and I still chose SPARK/Ada instead of Rust. SPARK is already certified for all of this. And aerospace, railway, and other high-integrity app industries are already familiar with the output of the SPARK tools, so there's less friction and time in auditing them for certification. Aside from AdaCore, who collaborated with Ferrocene, to get a compiler certified I don't see much traction to change our decision. We are creating show control software for cyber-physical systems with potential dire consequences, so we did a very in-depth study Q1 2025, and Rust came up short.

ForHackernews 11mo ago

> Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse. They already have a Rust toolchain for every system Debian releases for. The only architectures they're arguing about are non-official Debian ports for "Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4)", two of which are so obscure I've never even heard of them and one of the others most famous for powering retro video game systems like Sega Genesis.

oconnor663 11mo ago

> to rewrite some feature for a tiny security benefit For what it's worth, the zero->one introduction of a new language into a big codebase always comes with a lot of build changes, downstream impact, debate, etc. It's good for that first feature to be some relatively trivial thing, so that it doesn't make the changes any bigger than they have to be, and so that it can be delayed or reverted as needed without causing extra trouble. Once everything lands, then you can add whatever bigger features you like without disrupting things. No comment on the rest of the thread...