Hard Rust requirements from May onward • Hacker News Board

Re: Hard Rust requirements from May onward

#341

Post by kstrauser » Sat, Nov 01, 2025, 5:46 PM UTC

nyrikki wrote: post #334

OptionOfT wrote: post #230

Earlier quoted context omitted.

It would've saved the Mars Climate Orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter > An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]

That was only the proximate cause, the ultimate cause was cultural. As complex systems and efforts run into problems, it is trivial to blame the unit conversion when they had been ignoring people for months who had concerns [0] > ... ground controllers ignored a string of indications that something was seriously wrong with the craft's trajectory, over a period of weeks if not months. But managers demanded that worrie…

That's technically true, but if NASA's API accepted arguments in Meters instead of int32_t (or whatever the equivalent was in the language they used), then it would've been instantly obvious that the controller code that Lockheed Martin wrote was using the wrong datatype.

Re: Hard Rust requirements from May onward

#342

Post by egorfine » Sat, Nov 01, 2025, 5:46 PM UTC

ameliaquining wrote: post #197

egorfine wrote: post #174

Earlier quoted context omitted.

Even modern C++ is memory safe when used properly.

By that definition, all languages are "memory safe when used properly".

Well. Yes. Lol

Re: Hard Rust requirements from May onward

#343

Post by dathinab » Sat, Nov 01, 2025, 5:46 PM UTC

tacker2000 wrote: post #304

pezezin wrote: post #220

Earlier quoted context omitted.

I am pretty sure that those machines are not running Debian.

Why not? How do you know that? Debian is used pretty widely

they might run Debian but not upstream Debian/stable

you mainly find that with systems needing certification

this are the kind of situations where having a C language spec isn't enough but you instead need a compiler version specific spec of the compiler

similar they tend to run the same checkout of the OS with project specific security updates back-ported to it, instead of doing generic system updates (because every single updates needs to be re-certified)

but that is such a huge effort that companies don't want to run a full OS at all. Just the kernel and the most minimal choice of packages you really need and not one more binary then that.

and they might have picked Debian as a initial source for their packages, kernel etc. but it isn't really Debian anymore

Re: Hard Rust requirements from May onward

#344

Post by tialaramex » Sat, Nov 01, 2025, 5:47 PM UTC

mattbee wrote: post #333

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…

The Fil-C project ( https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.

If you're single platform (Fil-C is x86-64 only), if the program is finished (Fil-C doesn't magically make maintaining a C project any easier to handle) and if performance isn't relevant (Fil-C is and despite its originator's confidence always will be bigger and slower than what you have today) then I agree.

Re: Hard Rust requirements from May onward

#345

Post by simonw » Sat, Nov 01, 2025, 5:47 PM UTC

parliament32 wrote: post #331

It makes me uncomfortable that this mandate is coming from a Canonical employee. After all, if this switch was a good idea on merit alone, it would happen organically without requiring this kind of combative communication. What's the long-term play for Canonical here?

"What's the long-term play for Canonical here?"

Presumably it's rewriting critical parsing code in APT to a memory-safe language.

Re: Hard Rust requirements from May onward

#346

Post by vhantz » Sat, Nov 01, 2025, 5:47 PM UTC

bgwalter wrote: post #266

[flagged]

Is Debian linked to Canonical? Isn't tat Ubuntu?

Re: Hard Rust requirements from May onward

#347

Post by gpm » Sat, Nov 01, 2025, 5:47 PM UTC

bigyabai wrote: post #339

gpm wrote: post #247

Earlier quoted context omitted.

Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem. My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.

It depends, what language was the sandbox written in?

Sandboxes are difficult independent of language, see all the recent speculation vulnerabilities for instance. Sure, worse languages make it even harder, but I think we're straying from the original topic of "python/ruby" by considering sandboxes at all.

Re: Hard Rust requirements from May onward

#348

Post by loeg » Sat, Nov 01, 2025, 5:48 PM UTC

mattbee wrote: post #333

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…

The Fil-C project ( https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.

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

Re: Hard Rust requirements from May onward

#349

Post by loeg » Sat, Nov 01, 2025, 5:50 PM UTC

StopDisinfo910 wrote: post #261

Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.

The complaint about architecture support is somewhat valid (though: the world largely runs on a small handful of architectures). The other complaints are completely bogus, and repeatedly bringing them up just suggests bad faith.

Re: Hard Rust requirements from May onward

#350

Post by dvtkrlbs » Sat, Nov 01, 2025, 5:50 PM UTC

Xylakant wrote: post #310

dvtkrlbs wrote: post #250

Earlier quoted context omitted.

The problem is they forgot about making the language approachable so it lives in its bubble for safety criticial usage (which Rust kinda starting to eat its lunch from with the certified Rust fork)

If you’re referring to Ferrocene with the certified Rust fork, then I’d like to make the minor correction that we don’t consider Ferrocene a true fork, but rather a downstream distribution of the Rust projects compiler. There are very little changes to the compiler itself. Most relevant changes are documentation, build process and different test coverage - we do test architectures that upstream does not.

Yeah fork is a bad word for it. Sorry about that.