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

431–440 of 797 posts

Re: Hard Rust requirements from May onward

#431

Post by no_wizard »

fweimer wrote: post #422
throwaway2037 wrote: post #413

Earlier quoted context omitted.

Is X11/KDE considered part of the "base system"? If yes, then: > indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years ... isn't so surprising.

The Debian base system is much, much smaller. I'm surprised that people consider Python to be part of it. However, APT depends on Perl and the C++ run-time library, so those two languages have been part of the base system for a very long time.

I wonder how much of that Perl support is simply regex and other parsing utilities.

I’ve notice a lot of that in base OS systems

Its a curiosity more than anything though

Re: Hard Rust requirements from May onward

#433

Post by einpoklum »

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…

> Critical infrastructure still written in C ... is technical debt that is only going to get worse over time.

No. Rust is not magic, it just forces a discipline in which certain safety checks can be made automatically (or are obviated entirely). In other languages like C, the programmer needs to perform those checks; and it's technical debt if the C code is not coded carefully and reviewed for such issues. If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. And the safety of critical infra code written in C gets _better_ over time, as such technical debt is repaid.

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

That's not true. First, it's not a well-defined statement, since "what we know now" about language design is, as it has always been, a matter of debate and a variety of opinions. But even regardless of that - C was a language with certain design choices and aesthetics. Rust does not at _all_ share those choices - even if you tack on "and it must be safe". For example: Rust is much richer language - in syntax, primitive types, and standard library - than C was intended to be.

Re: Hard Rust requirements from May onward

#434

Post by pyrale »

allisdust wrote: post #204
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 a…

> Especially coming from the world of memory managed languages.

If people from that world complain about Rust, I surely wouldn't want them around a C codebase.

There's nothing wrong about memory-managed languages, if you don't need to care about memory. But being unfamiliar with memory and complaining about the thing that help you avoid shooting your foot isn't something that inspires trust.

The hardship associated with learning rust isn't going to go away if they do C instead. What's going to happen instead is that bugged code will be written, and they will learn to associate the hardship with the underlying problem: managing memory.

Re: Hard Rust requirements from May onward

#435

Post by jagged-chisel »

larusso wrote: post #426

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…

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.

Re: Hard Rust requirements from May onward

#436

Post by fizzynut »

kstrauser wrote: post #225
allisdust wrote: post #204

Earlier quoted context omitted.

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

I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); le…

This would get an error message in C, what are you talking about?

Re: Hard Rust requirements from May onward

#438

Post by cbmuser »

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…

> Who is still using these machines? Genuine question, not trolling.

Well, there are so many things were you could argue about the relevance of a userbase.

If the size of a userbase would be the only argument, Valve could just drop support for the Linux userbase which is just 2-3% of their overall userbase.

Re: Hard Rust requirements from May onward

#439

Post by cbmuser »

estimator7292 wrote: post #325
wk_end wrote: post #301

Earlier quoted context omitted.

There’s hobbyists using m68k Macs, Amigas, and Atari STs. Definitely a small niche, and those running Linux on those machines more so.

Sure, but almost nobody uses or wants modern linuxes on those machines. It's almost always described (in their own words) as "some ancient crusty version of Debian"

Nobody wants to play games on Linux given the small userbase compared to Windows. Yet people work on it.

You could make this argument for so many usecases but apparently people just enjoy bashing retrocomputing here.

Re: Hard Rust requirements from May onward

#440

Post by samdoesnothing »

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…

Oh please, in a decade Rust will also be technical debt and people will be wanting to write it in Brust or whatever is the trendy new language.
Post reply on HN