The timeline is not super abrupt, especially for architectures where all he is asking is to ensure that your Rust toolchain is in order. That is especially true when you consider that Rust is already well maintained on all the Debian architectures that people actually use.
The abruptness (almost rudeness) is in the second part where he basically says that, if you cannot get Rust going in time, you should just stop releasing Debian for that architecture.
It is mostly just poorly worded though. Because none of these architectures have “official” support even now. This will not be the only way they are behind. So, there is not reason to be so dramatic.
And that would be my response to him. Another option here is that these alternative architectures just continue to ship an older version of APT for now. Emergency avoided. Few of them ship with up-to-date versions of APT even now.
Another solution is to use one of the multiple projects that is working to make Rust code build with the GCC compiler back-end. At least one of these projects has already announced that they want to work with these Debian variants to ensure that APT builds with them.
So, the 6 month timeline is a reasonable impetus to make that happen which would be quite a good thing beyond just APT.
There are many other useful tools written in Rust you are going to want to use on these architectures. It will be a fantastic outcome if this pressure from APT kickstarts that happening for some of these long abandoned architectures (by the mainstream at least).
For package maintainers, it’s reasonable to expect security updates are rolled out the same week that a vulnerability is found. If you can’t deploy a new version of a package in 6 months, not maintaining the package is also a valid option.
There’s time until March for the maintainers of the 3 niche architectures to organize and make rust available for them. Doesn’t sound that abrupt to me
Rust adds another layer of trusting the compiler isn’t backdoored. All UNIX/Linux systems use the gcc toolchain, so having it written in C would mean less dependencies for the OS.
More like Rust has rotted someone’s brain. “Hey, I can’t code safely, so I will use this new toy that is supposed to make me”. This line of thought is OK as long as it does not get imposed on anything I do as a programmer
The industry cannot code safely. There are many reports, studies, and corporate disclosures highlighting that memory related bugs are the primary source of critical security issues in C and C++ code. That is why even NIH companies like Google and Microsoft are adopting Rust in their core products.
That you want to publicly ignore all that evidence to paint it as an individual skill issue does not come across as competent or intelligent. Few of us are going to assume your code is free of these kinds of bugs.
The fact that your have to say it so dismissively makes me think that you know it too.
Noticed an overall “vibe” where Rust critics repeatedly have points that sound like they make sense, and I can’t really think of examples of them saying confusing nonsense, or refusing to elaborate on a point when challenged to. Whereas, other way around for Rust defenders.
Best way I know to determine what’s “sus” is to look at what’s defended by people who are willing to elaborate on the points you ask them to elaborate on. It’s almost a perfect gauge. But maybe not quite perfect, and you could totally call it “vibes.” I remain not totally certain about Rust.
It’s very hard to get a good look at which arguments are good or not without having the experience to evaluate them.
Here’s my view on Rust vs C or C++. Rust is a stricter language which makes it easier to code with low run-time errors, which is great for writing large scale projects. Now the problem with this is that you can write C++ to also be strict but it’s a lot more verbose than the standard approach, so most developers don’t. This causes disagreement among Rustaceans and C/C++'ers. The C++'ers are correct that you can replicate anything in Rust in C++. A correct program is a correct program regardless of the language it’s written in. Rustaceans also oversell when it comes to program correctness, tons of Rust programs have errors; Rust can help minimize errors but it’s not a silver bullet. Rewriting-in-Rust for an already good program is a fools errand; the outcome will probably be a worse program. However Rustaceans are correct in pointing out that the C++ written programs tend to have more errors, it’s just not the rule they pretend it is.
In summary, Rust is a great language but Rustaceans oversell it. Many of it’s apparent advantages can be mitigated by good development practice. It’s just that good practices are difficult and uncommon.
(Note that there are also 3-rd party tools like static analysers, which can help developers detect errors. So again Rust is better out of the box, but ultimately you can get the same outcome with some work).
If you are not a programmer, you do not have the background or understanding to assess any arguments about a programing language.
The vast majority of anti-Rust people are stubborn and toxic types who don’t know it and refuse to learn. On the other end you have those who do use it, know why it’s such a good language, and criticize it constructively so that it continues to improve. Rust lacks many quality of life features that other languages have, but that is by design. It’s meant to create rock-solid software and forces you to think about things like lifetimes and ownership scopes that other languages let you take for granted.
You can’t easily move from languages like C++ or Python to Rust without learning and accepting new concepts and patterns. If someone can’t or won’t do that, they should not be doing any programming.
You care, you are the one that brought it up as an issue with rust.
I ask as a rhetorical question to shed light on the fact that compiler back doors are a vanishingly small fraction of total security exploits, while the memory bugs that rust specifically addresses make up the vast majority.
The vulnerability exploits a 13-year-old UAF memory corruption bug in Redis, allowing a post-auth attacker to send a crafted Lua script to escape the default Lua sandbox and execute arbitrary native code. This grants full host access, enabling data theft, wiping, encryption, resource hijacking, and lateral movement within cloud environments.
13 years. That’s how long it took to find a critical safety vulnerability in one of the most popular C open source codebases, Redis. This is software that was expertly written by some of the best engineers in the world and yet, mistakes can still happen! It’s just that in C a “mistake” can often mean a memory-safety bug that would put user data at risk (…) That’s the nature of memory-safety bugs in C: they can hide in plain sight.
And while you bring up a “boo-hoo, software written in C has bugs” common knowledge, to my best knowledge standard Rust library still has unsafe parts. But that’s no problem, because contracts, sure. Thanks for demonstrating how full of nonsense you are, bye
it’s weird how often these same strawman arguments are the response when Rust’s safety advantage over C comes up. Usually the same adolescent tone too.
The vulnerability exploits a 13-year-old UAF memory corruption bug in Redis, allowing a post-auth attacker to send a crafted Lua script to escape the default Lua sandbox and execute arbitrary native code. This grants full host access, enabling data theft, wiping, encryption, resource hijacking, and lateral movement within cloud environments.
13 years. That’s how long it took to find a critical safety vulnerability in one of the most popular C open source codebases, Redis. This is software that was expertly written by some of the best engineers in the world and yet, mistakes can still happen! It’s just that in C a “mistake” can often mean a memory-safety bug that would put user data at risk (…) That’s the nature of memory-safety bugs in C: they can hide in plain sight.
Why did you make me read these paragraphs without explaining how they connect to the context? Let me guess: they don’t connect to the context, you’re just designing your replies to mislead people dumb enough to be vulnerable to your manipulation tactics? With no consideration for me whose time/energy you’re wasting, much less them who you’re confusing?
You know that bans/removals are documented right? If you don’t see your post it’s because you didn’t post it. You’re not being censored, go take your meds
Weak gaslighting attempt but if you could show me where to find it documented I would appreciate that.
If anyone is confused, feel free to ask me for proof I’m telling the truth. If I posted it here, I’m pretty sure I’d be at risk of getting banned for evading the post removal (because the proof would also lead you back to the reply chain that was removed)
Edit - maybe this counts as proof without showing any removed content:
Is it just me, or does that seem … abrupt?
The timeline is not super abrupt, especially for architectures where all he is asking is to ensure that your Rust toolchain is in order. That is especially true when you consider that Rust is already well maintained on all the Debian architectures that people actually use.
The abruptness (almost rudeness) is in the second part where he basically says that, if you cannot get Rust going in time, you should just stop releasing Debian for that architecture.
It is mostly just poorly worded though. Because none of these architectures have “official” support even now. This will not be the only way they are behind. So, there is not reason to be so dramatic.
And that would be my response to him. Another option here is that these alternative architectures just continue to ship an older version of APT for now. Emergency avoided. Few of them ship with up-to-date versions of APT even now.
Another solution is to use one of the multiple projects that is working to make Rust code build with the GCC compiler back-end. At least one of these projects has already announced that they want to work with these Debian variants to ensure that APT builds with them.
So, the 6 month timeline is a reasonable impetus to make that happen which would be quite a good thing beyond just APT.
There are many other useful tools written in Rust you are going to want to use on these architectures. It will be a fantastic outcome if this pressure from APT kickstarts that happening for some of these long abandoned architectures (by the mainstream at least).
For package maintainers, it’s reasonable to expect security updates are rolled out the same week that a vulnerability is found. If you can’t deploy a new version of a package in 6 months, not maintaining the package is also a valid option.
but this is not a vulnerability, but adding a cpu architecture to a programming language
There’s time until March for the maintainers of the 3 niche architectures to organize and make rust available for them. Doesn’t sound that abrupt to me
For small niches, six months can be rather aprupt.
My niche can take 5 days or 5 months, depending on ADHD
Wasn’t there a Rust-to-C compiler that would circumvent this limitation?
Yes. There is also a GCC front-end for Rust (does not go to C first).
Strange times.
how many compiler back doors have we seen versus use-after-free/stack overflow attacks?
The anti-Rust crowd baffles me. Maybe C++ has rotted their brain to the point they can’t “get” the borrow checker.
My only complaint is that its syntax is an ugly mishmash. Should have copied scala or f#
More like Rust has rotted someone’s brain. “Hey, I can’t code safely, so I will use this new toy that is supposed to make me”. This line of thought is OK as long as it does not get imposed on anything I do as a programmer
The industry cannot code safely. There are many reports, studies, and corporate disclosures highlighting that memory related bugs are the primary source of critical security issues in C and C++ code. That is why even NIH companies like Google and Microsoft are adopting Rust in their core products.
That you want to publicly ignore all that evidence to paint it as an individual skill issue does not come across as competent or intelligent. Few of us are going to assume your code is free of these kinds of bugs.
The fact that your have to say it so dismissively makes me think that you know it too.
Who cares? Why do you ask?
I can’t code, so C++ doesn’t have much space in my brain, but Rust still seems a lot more sus to me than C.
Rust seems sus to you? What’s that based on, “vibes, bro”?
Essentially, yeah.
Noticed an overall “vibe” where Rust critics repeatedly have points that sound like they make sense, and I can’t really think of examples of them saying confusing nonsense, or refusing to elaborate on a point when challenged to. Whereas, other way around for Rust defenders.
Best way I know to determine what’s “sus” is to look at what’s defended by people who are willing to elaborate on the points you ask them to elaborate on. It’s almost a perfect gauge. But maybe not quite perfect, and you could totally call it “vibes.” I remain not totally certain about Rust.
It’s very hard to get a good look at which arguments are good or not without having the experience to evaluate them.
Here’s my view on Rust vs C or C++. Rust is a stricter language which makes it easier to code with low run-time errors, which is great for writing large scale projects. Now the problem with this is that you can write C++ to also be strict but it’s a lot more verbose than the standard approach, so most developers don’t. This causes disagreement among Rustaceans and C/C++'ers. The C++'ers are correct that you can replicate anything in Rust in C++. A correct program is a correct program regardless of the language it’s written in. Rustaceans also oversell when it comes to program correctness, tons of Rust programs have errors; Rust can help minimize errors but it’s not a silver bullet. Rewriting-in-Rust for an already good program is a fools errand; the outcome will probably be a worse program. However Rustaceans are correct in pointing out that the C++ written programs tend to have more errors, it’s just not the rule they pretend it is.
In summary, Rust is a great language but Rustaceans oversell it. Many of it’s apparent advantages can be mitigated by good development practice. It’s just that good practices are difficult and uncommon.
(Note that there are also 3-rd party tools like static analysers, which can help developers detect errors. So again Rust is better out of the box, but ultimately you can get the same outcome with some work).
That all lines up with what I’ve heard. Thanks for the comprehensive reply 🤙
If you are not a programmer, you do not have the background or understanding to assess any arguments about a programing language.
The vast majority of anti-Rust people are stubborn and toxic types who don’t know it and refuse to learn. On the other end you have those who do use it, know why it’s such a good language, and criticize it constructively so that it continues to improve. Rust lacks many quality of life features that other languages have, but that is by design. It’s meant to create rock-solid software and forces you to think about things like lifetimes and ownership scopes that other languages let you take for granted.
You can’t easily move from languages like C++ or Python to Rust without learning and accepting new concepts and patterns. If someone can’t or won’t do that, they should not be doing any programming.
You care, you are the one that brought it up as an issue with rust.
I ask as a rhetorical question to shed light on the fact that compiler back doors are a vanishingly small fraction of total security exploits, while the memory bugs that rust specifically addresses make up the vast majority.
About random numbers? Not really
Are you referring to where I said “I want to know some random numbers Rust isn’t giving me, and that’s a problem with Rust?”
Because that was in your imagination.
Or are you referring to where I said “Rust wants to know some random numbers it isn’t giving itself?”
Because that was also in your imagination.
In reality, I brought up that I’ve heard Rust adds another layer of trusting the compiler isn’t backdoored.
While you’re spouting nonsense, this is happening:
https://www.infoq.com/news/2025/11/redis-vulnerability-redishell/
And while you bring up a “boo-hoo, software written in C has bugs” common knowledge, to my best knowledge standard Rust library still has unsafe parts. But that’s no problem, because contracts, sure. Thanks for demonstrating how full of nonsense you are, bye
it’s weird how often these same strawman arguments are the response when Rust’s safety advantage over C comes up. Usually the same adolescent tone too.
I’m the guy you were replying to here. I’m not spouting any nonsense in this thread. Did you reply to the wrong person, or is this a false accusation?
Why did you make me read these paragraphs without explaining how they connect to the context? Let me guess: they don’t connect to the context, you’re just designing your replies to mislead people dumb enough to be vulnerable to your manipulation tactics? With no consideration for me whose time/energy you’re wasting, much less them who you’re confusing?
Our team has reviewed this interaction, and cannot issue a refund at this time.
Strange how your bad faith reply is still here, and with many upvotes, while my reply calling you out appears to be gone.
This is an example of how discussions like this are more appropriate for nostr, where there are no bans / post removals.
You know that bans/removals are documented right? If you don’t see your post it’s because you didn’t post it. You’re not being censored, go take your meds
Weak gaslighting attempt but if you could show me where to find it documented I would appreciate that.
If anyone is confused, feel free to ask me for proof I’m telling the truth. If I posted it here, I’m pretty sure I’d be at risk of getting banned for evading the post removal (because the proof would also lead you back to the reply chain that was removed)
Edit - maybe this counts as proof without showing any removed content:
https://piefed.social/post/1458050/comment/8784509#replies
If you click the link, it’s blank, yet it has a “parent comment” link that leads to where I was replying
Edit 2 - tried to post an archive link but archive.org didn’t seem to work the way I thought?
Is the link I posted above showing what I described for other users?
Can confirm that post still exists. I just downvoted it. Still exists when I open the link you posted in a browser, too, just collapsed.
https://lemmy.zip/modlog?page=1&actionType=All&userId=25498760
Nope, not seeing it there
Yeah I know you don’t. It’s because your comments aren’t being removed
There’s an ongoing effort to get gcc to compile Rust.[1]
https://lwn.net/Articles/907405/ ↩︎
This seems relevant:
https://youtu.be/Fu3laL5VYdM
yes very, and I hate it. rustic metal is never good ffs!