Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

201–210 of 797 posts

Re: Hard Rust requirements from May onward

#201

Post by UncleEntity »

mirashii wrote: post #172
Surac wrote: post #94

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

> I think this is the wrong way to promote rust This is entirely the wrong lens. This is someone who wants to use Rust for a particular purpose, not some sort of publicity stunt. > I know nobody that programms or even thinks about rust. I’m from the embedded world a there c is still king. Now’s a good time to look outside of your bubble instead of pretending that your bubble is the world. > as long as the real money…

> This is entirely the wrong lens.

Telling people they need to take their ball and go home if they're incapable or unable to maintain an entire compiler back-end seems like a, shall we say, 'interesting' lens for a major distro such as Debian.

Just to parse some files?

Re: Hard Rust requirements from May onward

#202

Post by gpm »

astockwell wrote: post #194
lambdaone wrote: post #161

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 dro…

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?

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.

Re: Hard Rust requirements from May onward

#203

Post by mirashii »

einpoklum wrote: post #84
mirashii wrote: post #60

Earlier quoted context omitted.

> 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.

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…

It feels like perhaps you’ve conflated the issue in this thread, which is about using Rust in apt, which is much, much later in the distribution bringup than this bootstrapping, and using Rust in something like the Linux kernel, which is more relevant to those types of bootstrapping discussions you posted.

apt is so late in the process that these bootstrapping discussions aren’t quite so relevant. My point was that at the same layer of the OS, there are many, many components that don't meet the same criteria posted, including perl.

Re: Hard Rust requirements from May onward

#204

Post by allisdust »

lambdaone wrote: post #161

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 dro…

Sadly most people don't agree with this

I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash.

It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back against any and every use, promotion of Rust. The unknown fear seem to be that they will be left behind if it takes off.

I completed my battles with Rust. I don't even use it anymore (because of lack of opportunities). But I love Rust. It is here to stay and expand. Thanks to the LLMs and the demand for verifiability.

Re: Hard Rust requirements from May onward

#205

Post by Denvercoder9 »

mid-kid wrote: post #75

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 bei…

> 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.

Re: Hard Rust requirements from May onward

#206

Post by tempest_ »

astockwell wrote: post #194
lambdaone wrote: post #161

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 dro…

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?

Yes, which is why in 2025 it is a good idea to use Rust with python bindings for your performance sensitive code.

A lot of the C code used in python is calling out to old, battle tested and niche libraries so it is unlikely that someone is going to replace those any time soon but Rust is definitely increasing as time goes on for greenfield work.

Re: Hard Rust requirements from May onward

#207

Post by atoav »

Surac wrote: post #94

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

I program mostly Python, C, C++, Javascript and Rust. Including on embedded (that goes for C, C++ and Rust)

Most people nowadays who criticize Rust do so on a cultural basis of "there are people who want this so and it changes things therefore it is bad". But never on the merits.

Rust is a good language that contains in its language design some of the lessons the best C programmers have internalized. If you are a stellar C programmer you will manually enforce a lot of the similar rules that Rust enforces automatically. That doesn't mean Rust is a cage. You can always opt for unsafe if ypu feel like it.

But I know if my life depended on it I would rather write that program in Rust than in C, especially if it involves concurrency or multiprocessing.

Practically on embedded the issue is that most existing libraries are written in C or C++. That can be a reason to not choose it in the daily life. But it is not a rational reason for which a programming language sucks. Every programming language had once only one user. Every programming language had once no dependencies written in it. Rust is excellent in letting you combine it with other languages. The tooling is good. The compiler error messages made other language realize how shitty their errors were.

Even if nobody programmed in Rust, the good bits of that language lift the quality in the other languages.

Re: Hard Rust requirements from May onward

#208

Post by wartywhoa23 »

nikanj wrote: post #15

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

If I was a blackhat, I'd surely value all pre-IntelME / AMD PSP *retro-computing* hardware that is still capable of running more or less modern software without a built-in hardware backdoor higher than its weight in gold.

Re: Hard Rust requirements from May onward

#209

Post by 3eb7988a1663 »

thesuperbigfrog wrote: post #138
justinclift wrote: post #6

One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html > Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv). Wonder what this means for those architectures then?

Who is still using these machines? Genuine question, not trolling. It looks like the last machines of each architecture were released: Alpha in 2007 HP-PA in 2008 m68k in pre-2000 though derivatives are used in embedded systems sh4 in 1998 (though possible usage via "J2 core" using expired patents) This means that most are nearly 20 years old or older. Rust target triples exist for: m68k: https://doc.rust-lang.org/ni…

Debian just cut i386, Wikipedia says the i386 was discontinued in 2007. These systems are all of the same vintage, so it does not seem a huge leap to be culled from the support list.

[0] https://en.wikipedia.org/wiki/I386

Re: Hard Rust requirements from May onward

#210

Post by [deleted] »

egorfine wrote: post #183

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 Pasc…

[deleted]
Post reply on HN