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

591–600 of 797 posts

Re: Hard Rust requirements from May onward

#591

Post by Greed »

jbv027 wrote: post #397
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…

It is not only about memory safety. C community is aging fast and young developers choose different languages. We started to rewrite all C and C++ code in my team because it is really hard to find people willing to maintain it. From my experience typical C or C++ programer is around 40 and not willing to switch jobs.

Wow, I've never considered this aspect of it but you're right. If you want widespread access to incoming developers that can contribute to your project, that really does mean Rust by default at this point if you want a low level language regardless of what you prefer.

Re: Hard Rust requirements from May onward

#592

Post by mkl »

uecker wrote: post #297
crote wrote: post #61

Earlier quoted context omitted.

> I think the spin that Rust is necessarily the way forward is what is wrong. Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that. C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad c…

While memory safety is important, I do not believe it is now suddenly so important that it needs now needs to be solved quickly at all cost. There are far more pressing issues. I also do not think at all that C/C++ are dead end. In fact, I think it would be far more cost effective to continue to improve safety of C and C++ code via gradual improvement than adding another language into the mix. The reason is that comp…

English link: https://www.debian.org/releases/trixie/release-notes/issues....

> The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably.

Re: Hard Rust requirements from May onward

#593

Post by RustSupremacist »

jbv027 wrote: post #397
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…

It is not only about memory safety. C community is aging fast and young developers choose different languages. We started to rewrite all C and C++ code in my team because it is really hard to find people willing to maintain it. From my experience typical C or C++ programer is around 40 and not willing to switch jobs.

Inviting rank amateurs to established projects while expecting them to operate as free labor in the hopes of future relevance for employment has a distinctly different feel. Missives like the OP feel like preying on a desperate and young generation when paired with the commentary.

If all the entry-level jobs are C or C++, do you think companies would have a hard time filling them? Would the unemployed new graduates really shun gainful employment if Rust wasn't part of the equation?

Meanwhile, hiring managers left and right are reporting that within hours of a job being posted, they are flooded with hundreds of applications. And you can't find a single person because of the programming language of your stack? And to remedy this, you're going to rewrite your stack in an unproven language? Have you considered that if you can't find anyone that it might not be a programming language or tech stack problem?

Re: Hard Rust requirements from May onward

#594

Post by steveklabnik »

kasabali wrote: post #542
steveklabnik wrote: post #522

Earlier quoted context omitted.

You’re the one that said ten years.

You're the one who said "ten years since Rust 1.0 "

Right, that’s when Rust was new and shiny. People who chase the latest new shiny thing don’t consider ten year old technology new and shiny, they’d have moved on years ago.

Re: Hard Rust requirements from May onward

#595

Post by LtWorf »

loeg wrote: post #357
3eb7988a1663 wrote: post #209

Earlier quoted context omitted.

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

Yeah, and you can still run i386 binaries on widely available amd64 CPUs. So this is an even stronger argument for killing these other obsolete platforms.

You can only run the binaries if you have the libc to run them.

Re: Hard Rust requirements from May onward

#596

Post by cozzyd »

mike_d wrote: post #570
jcranmer wrote: post #316

Earlier quoted context omitted.

Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to lear…

> there are approximately five languages that are presumed to be acceptable for core applications in the base system: [...] Python I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in. Core system applications should be binaries that run with absolutely minimal de…

this is not normally a problem for a distro where the environment is well known

Re: Hard Rust requirements from May onward

#597

Post by kouteiheika »

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.

Either legacy systems (which are most certainly not running the current bleeding-edge Debian) or retro computing enthusiast.

These platforms are long obsolete and there are no practical reasons to run them besides "I have a box in the corner that's running untouched for the last 20 years" and "for fun". I can get a more powerful and power efficient computer (than any of these systems) from my local e-waste recycling facility for free.

Re: Hard Rust requirements from May onward

#598

Post by ashirviskas »

cozzyd wrote: post #596
mike_d wrote: post #570

Earlier quoted context omitted.

> there are approximately five languages that are presumed to be acceptable for core applications in the base system: [...] Python I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in. Core system applications should be binaries that run with absolutely minimal de…

this is not normally a problem for a distro where the environment is well known

Can you expand? I'm honestly curious how it is not a problem in Pythons case

Re: Hard Rust requirements from May onward

#600

Post by hunterpayne »

julian-klode wrote: post #514
Defletter wrote: post #184

Earlier quoted context omitted.

The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.

Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change. As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.

All these changes requires work. Because of this, other priorities will get less attention. It would be ironic if bad security flaws are missed/introduced because of all the work switching to Rust. Its also very likely that all the new code written in Rust will be far less mature than the existing source bases. So the outcome might be (very probably actually) a lot of work to worsen security.

Most of the academic research into these sorts of typesafe languages usually returns the null result (if you don't agree, it means you haven't read the research on this topic). That's researcher for it didn't work and you shouldn't be using these techniques. Security is a process, not a silver bullet and 'just switch to Rust' is very silvery bullet.

Post reply on HN