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

561–570 of 797 posts

Re: Hard Rust requirements from May onward

#561

Post by RustSupremacist »

MerrimanInd wrote: post #448
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…

I've heard two arguments for these rewrites that don't always come up in these discussions. There are fair counterpoints to both of these but I think they add valuable dimensions to the conversation, or perhaps may explain why a rewrite may not seem justified without them. * It's becoming increasingly difficult to find new contributors who want to work with very old code bases in languages like C or C++. Some open so…

Inviting inexperienced amateurs to wide-reaching projects does not seem to be a prudent recipe. Nay, it is a recipe for disaster.

Re: Hard Rust requirements from May onward

#562

Post by woodruffw »

jpgvm wrote: post #549
woodruffw wrote: post #544

Earlier quoted context omitted.

I'm not following: Rust excels at C interop, so why wouldn't you use the OEM drivers/SDK and bind them through Rust for your own code? That's what I've always done when I need to interact with a C library in Rust.

So the main reason that doesn't work sometimes is how you are using Rust. For instance right now I'm leaning into the Rust Embassy ecosystem which is async based, the drivers need relatively deep integration with the embedded-hal-async layer which is far from trivial to do with C bindings. In practice I end up rewriting drivers. Which sounds daunting but often times it's much easier than folks think and the resulting…

That's a scenario I hadn't considered, thanks!

Re: Hard Rust requirements from May onward

#564

Post by chuckadams »

samdoesnothing wrote: post #440
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.

C's been around for over 50 years. Yes, I would hope that something does replace replace Rust after 50 years.

Re: Hard Rust requirements from May onward

#565

Post by octoberfranklin »

throwaway2037 wrote: post #408

The follow-up is solid gold: > I find this particular wording rather unpleasant and very unusual to what I'm used to from Debian in the past. I have to admit that I'm a bit disappointed that such a confrontational approach has been chosen. Ref: https://lists.debian.org/debian-devel/2025/10/msg00286.html

Definitely the adult in the room.

Re: Hard Rust requirements from May onward

#566

Post by pezezin »

kortilla wrote: post #472
pezezin wrote: post #220

Earlier quoted context omitted.

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

You would be wrong. People want new software

If we are talking about embedded control systems no, you don't want new software, you want your machine to do what is supposed to do. At my workplace we have some old VME crates running VxWorks, and nobody is gonna update those to the latest Linux distro.

Re: Hard Rust requirements from May onward

#567

Post by [deleted] »

kstrauser wrote: post #286
thaumasiotes wrote: post #259

Earlier quoted context omitted.

I sometimes think about a related issue: suppose you have a function whose n parameters have n different types. Should the programmer be required to provide those parameters in a specific order? There's no ambiguity. There appears to be some tension between different conveniences you might afford yourself. If you have read(offset: offsetTypeForRead, address: addressTypeForRead), you can catch when someone accidentall…

Huh, that’s an interesting point, and I’d have to think on that. There are still plenty of cases where ordering would matter, like subtract(a,b), unless you go whole hog and define that like fn sub(a:LeftOp, b:RightOp) but that seems redundant. There are still plenty of other cases where I could your idea being useful. Like I always forget whether (in Python) it’s json.dump(file, data) or dump(data, file). Ultimately…

[deleted]

Re: Hard Rust requirements from May onward

#568

Post by bsder »

woodruffw wrote: post #544
lpribis wrote: post #394

Earlier quoted context omitted.

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

I'm not following: Rust excels at C interop, so why wouldn't you use the OEM drivers/SDK and bind them through Rust for your own code? That's what I've always done when I need to interact with a C library in Rust.

> I'm not following: Rust excels at C interop

Zig is an example of excelling at C interop--not Rust.

And Cargo is an impediment in the embedded ecosystem rather than a bonus.

Part of why we're getting Rewrite-it-in-Rust everywhere is precisely because the C interop is sufficiently weak that you can't do things easily in a piecemeal fashion.

And lets not talk about Rust compile times and looking at Rust code in a debugger and just how bad Rust code is in debug mode ...

Re: Hard Rust requirements from May onward

#569

Post by Seattle3503 »

richard_todd wrote: post #550

I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting,…

Thats exactly what happed with ripgrep. People seem to like it.

Re: Hard Rust requirements from May onward

#570

Post by mike_d »

jcranmer wrote: post #316
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…

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 dependencies outside of default system-wide libraries. Heck, I would go as far as to say applications in the critical path to repairing a system (like apt) should be statically linked since we no longer live in a storage constrained world.

Post reply on HN