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

451–460 of 797 posts

Re: Hard Rust requirements from May onward

#451

Post by zygentoma »

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…

> It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried.

That could also be applied to C and C++ …

Re: Hard Rust requirements from May onward

#452

Post by rcxdude »

josefx wrote: post #416

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.

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.

Re: Hard Rust requirements from May onward

#453

Post by jodrellblank »

dokyun wrote: post #418
thiht wrote: post #116

Earlier quoted context omitted.

> I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries. Not sure how that’s relevant when CL is basically dead and no one wants to work with it, while Rust is flourishing and delivering value

Rust isn't 'delivering value', people are just drinking the koolaid. CL has its niches, and it still fills them well: it's never been that successful as a general-purpose language.

> Rust isn't 'delivering value'

Citation needed.

Or, what can be asserted without evidence can be dismissed by pointing to ripgrep.

Re: Hard Rust requirements from May onward

#455

Post by collinfunk »

TuxSH wrote: post #441
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…

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

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

Re: Hard Rust requirements from May onward

#456

Post by sesm »

thiht wrote: post #116
noosphr wrote: post #13

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.

> I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries. Not sure how that’s relevant when CL is basically dead and no one wants to work with it, while Rust is flourishing and delivering value

If the value proposition is internet drama, then it certainly does.

Re: Hard Rust requirements from May onward

#457

Post by Too »

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…

It’s usually a loud minority of trolls or hobbyists. It just takes one to spark a doubt.

Here is one famous example of a dude who’s managed to get PRs merged in dozens of packages, just to make them compatible with ancient versions of nodejs https://news.ycombinator.com/item?id=44831811

Re: Hard Rust requirements from May onward

#458

Post by Avamander »

einpoklum wrote: post #433
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…

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

How many decades have we tried this? How many more to see that it just hasn't panned out like you describe?

Re: Hard Rust requirements from May onward

#459

Post by adwn »

throwawaymaths wrote: post #421
kstrauser wrote: post #225

Earlier quoted context omitted.

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…

How does this scheme of yours work with m/s and seconds. IIUC, rust would NOT let you do a type checked m/s * s => m, so using the type system for these kinds of games is silly and dangerous (I presume you would have to do the dumb thing and typeconvert to the same type -- e.g. (m) (speed * ((m/s) seconds)) to do multiplication which means you're inserting unscientific and reader-confusing type conversions all over t…

That's no problem in Rust. You can have a Speed type and a Time type, and define the multiplication operator over them to return a Length value. In fact, there's already a library which does exactly that, with tons of predefined SI units: https://docs.rs/uom/latest/uom/

Re: Hard Rust requirements from May onward

#460

Post by cardanome »

TuxSH wrote: post #441
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…

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

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?

Post reply on HN