Hard Rust requirements from May onward • Hacker News Board

Re: Hard Rust requirements from May onward

#391

Post by the_duke » Sat, Nov 01, 2025, 6:45 PM UTC

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…

Anyone capable of programming and willing to invest enough time will be able to learn Rust, in my opinion.

It might take some people months rather than days, but I think that is a desirable outcome.

Important low level software should be written by competent developers willing to invest the effort.

Re: Hard Rust requirements from May onward

#392

Post by threemux » Sat, Nov 01, 2025, 6:46 PM UTC

In the end, only NetBSD will be standing in the breach after anything not x64 or ARMv8+ is declared "retro computing".

Re: Hard Rust requirements from May onward

#393

Post by blub » Sat, Nov 01, 2025, 6:53 PM UTC

coderjames wrote: post #368

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…

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > 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. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and…

Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :)

Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…

Re: Hard Rust requirements from May onward

#394

Post by lpribis » Sat, Nov 01, 2025, 6:54 PM UTC

the__alchemist wrote: post #141

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

Rust slaps on embedded too; I think that's one of its core competencies. But you have to do a lot of leg work for each piece of hardware because manufacturer support isn't there, and the OSS libs are usually not great. If your requirement is "Use only the most popular language in this domain", that's fine, but there's no point in evaluating or discussing other languages if so; the outcome is predetermined. I think th…

The unfortunate reality is that you must write almost all of your drivers from scratch if you want to rust in embedded. There is no OEM driver support, and as you said the open source drivers are all crap and written for arduino-level hobby projects.

Lack of drivers is prohibitive if your are a small/medium team or are using a lot of complicated peripherals or SoC. Compare to C where any MCU or embedded SoC or moderately complex peripheral normally comes with C driver code.

Re: Hard Rust requirements from May onward

#395

Post by the_duke » Sat, Nov 01, 2025, 6:56 PM UTC

pron wrote: post #228

Measter wrote: post #168

Earlier quoted context omitted.

Zig only does bounds checking by default in Debug and ReleaseSafe builds. If you build with ReleaseFast or ReleaseSmall it will happily do an out of bounds read: https://godbolt.org/z/733PxPEPY

That's a matter of how policy is set. You can set it to on or off for a particular function, too. The point is that language offers sound spatial safety just as much as Rust does (and both allow you to turn it on or off in particular pieces of code).

Defaults and ecosystem approach matter a lot, though.

The whole Rust ecosystem is heavily biased towards prioritising memory safety and "safe by construction" .

This is evident in the standard library, in how crates approach API design, what the compilation defaults are, ...

In 6+ years of using Rust the only time I had to deal with segfaults was when working on low level wrappers around C code or JIT compilation.

Zig has some very interesting features, but the way they approach language and API design leaves a lot of surface area that makes mistakes easy.

Re: Hard Rust requirements from May onward

#396

Post by CodesInChaos » Sat, Nov 01, 2025, 6:57 PM UTC

curt15 wrote: post #130

zozbot234 wrote: post #42

Earlier quoted context omitted.

m68k has a LLVM port already, so Rust can be implemented for that platform.[0] It would be nice to have LLVM backends for alpha, hppa and sh4 - these older architectures tend to be quite simple so a working LLVM has plenty of value as a reference and for educational use. (LLVM even used to have an in-tree DEC Alpha backend, though that was back in 2011 and not relevant to any version of Rust.) [0] Looks like there is…

Shouldn't the codegen_gcc project[1] theoretically allow Rust to target backends that only GCC supports? [1] https://github.com/rust-lang/rustc_codegen_gcc

https://lists.debian.org/debian-devel/2025/11/msg00010.html

Re: Hard Rust requirements from May onward

#397

Post by jbv027 » Sat, Nov 01, 2025, 6:57 PM UTC

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.

Re: Hard Rust requirements from May onward

#398

Post by Denvercoder9 » Sat, Nov 01, 2025, 6:59 PM UTC

coderjames wrote: post #368

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…

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > 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. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and…

> But hasn't all that foundational code been stable and wrung out already over the last 30+ years?

No: a little less than 5 years ago there was CVE-2020-27350, a memory safety bug in the tar/ar implementations.

Re: Hard Rust requirements from May onward

#399

Post by kaoD » Sat, Nov 01, 2025, 7:02 PM UTC

hypeatei wrote: post #146

zozbot234 wrote: post #93

Earlier quoted context omitted.

Swift is also memory safe in that sense.

Swift uses Automatic Reference Counting (ARC) which is a form of garbage collection.

Not sure why you're downvoted, RC is definitely a form of GC even if not a tracing GC.

Re: Hard Rust requirements from May onward

#400

Post by loeg » Sat, Nov 01, 2025, 7:04 PM UTC

mattbee wrote: post #388

loeg wrote: post #348

Earlier quoted context omitted.

Making core package infrastructure 10x slower doesn't seem especially pragmatic.

The author's benchmarks suggest 10× would be a pathological case! But even so - what price correct & secure software? We all lost a tonne of performance overnight when we applied the first Meltdown and Spectre workarounds. This doesn't seem much different.

We have an alternative that isn't 10x slower, and comes with many other benefits (Rust). The only cost is losing hardware support for some very obsolete and very unpopular platforms. (Nevermind that Fil-C's hardware support is narrower than Rust's.)