Hard Rust requirements from May onward • Hacker News Board

Re: Hard Rust requirements from May onward

#741

Post by pizlonator » Sun, Nov 02, 2025, 4:39 PM UTC

lucyjojo wrote: post #697

pizlonator wrote: post #558

Earlier quoted context omitted.

> as easily as fixing Rust to work on the remaining 4 architectures? Easier, because you won't have to port Fil-C to all of the architectures in order to use it on amd64. > C++ doesn't attract a lot of developers, Rust attracts many more. C is #2 on TIOBE. C++ is #3 on TIOBE. Rust is #16 on TIOBE. So I don't know what you're talking about

he just said from experience that switching projects to rust got them many new contributors. i guess it's cool for c(++) to have nice tiobe rankings but if they're not contributing how is that relevant?

He got a lot of contributors because those contributors wanted to participate in a rewrite. I.e. the opportunity to "move fast and break things". Not exactly the kind of contributions you should be looking for in a package manager that so many of us rely on.

If he was asking for C/C++ contributors, he'd be asking for help maintaining a mature project. That's less fun. It mature, grown-up work for serious people. Those serious people probably already have serious jobs. So, fewer people will show up.

Re: Hard Rust requirements from May onward

#742

Post by julian-klode » Sun, Nov 02, 2025, 4:54 PM UTC

aragilar wrote: post #584

dvtkrlbs wrote: post #271

Earlier quoted context omitted.

Pretty consistently [1] [2] [3] [4] it comes out that nearly %80 of security vulnerabilities come from memory safety vulnerabilities. I would consider that largest. Especially Microsoft's doc is pretty telling that this ratio was pretty consistent since 2006 so no amount of external tooling and training solves this. [1] https://langui.sh/2019/07/23/apple-memory-safety/ (albeit apple solving this with an another langu…

In which code though? What counts as a security vulnerability (does the design of the play store such that searching for an app and the top result not being that app count)? I like everyone else want a secure browser, but my secure browser isn't going to prevent my email (or passwords) from appearing on https://haveibeenpwned.com/ . I like rust, and want to write more rust, but if I were to port openssh to rust, I gu…

> though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs

I think that's much more likely to introduce bugs.

Think of it that way, a lot of the Rust libraries are rewriting existing copyleft libraries in permissive licenses, so they cannot look at the original code, dooming them to repeat the mistakes that were made in the original code and having to fix them all over again on their own (as both go from "oh this is simple" to "oh another corner case").

I just want to translate code 1:1 to Rust, reusing my existing knowledge, design decisions, and tests. It should behave _exactly_ the same as before, just memory safe.

Re: Hard Rust requirements from May onward

#743

Post by jeroenhd » Sun, Nov 02, 2025, 5:04 PM UTC

bgwalter wrote: post #499

jeroenhd wrote: post #437

Earlier quoted context omitted.

If only more people were willing to let their opinions be changed over time like that, rather than clinging onto them.

If only a reason were given. This is the original: > Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update. What has changed? Why is 130 packages for a crypto application acceptable?

That's not a Rust problem, that's a sequoia problem.

As for why, probably the same reason the dependency tree for gnupg (generate with `debtree -R -b gnupg` but grepping out all the gcc/mingw dependencies) looks like this: https://static.jeroenhd.nl/hn/gnupg.svg There's probably a good reason why I need libjpeg62, libusb-1.0-0-dev, and libgmp3 to compile gnupg, though they're hidden away from the usual developer docs in the form of transitive dependencies; complex software just tends to include external dependencies rather than reinventing the wheel.

Re: Hard Rust requirements from May onward

#744

Post by [deleted] » Sun, Nov 02, 2025, 5:14 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…

[deleted]

Re: Hard Rust requirements from May onward

#745

Post by zahlman » Sun, Nov 02, 2025, 5:30 PM UTC

throwaway7356 wrote: post #688

zahlman wrote: post #608

Earlier quoted context omitted.

> I'm surprised that people consider Python to be part of it. However, APT depends on Perl Pardon? $ file `which apt` /usr/local/bin/apt: Python script, ASCII text executable

Debian doesn't ship files in /usr/local. You can of course add your own "apt" binary in /usr/local/bin/apt which can be written in any language you like, say COBOL, Java, Common Lisp or Python.

Ah, of course. I guess this wrapper is provided by Mint.

Re: Hard Rust requirements from May onward

#746

Post by bastawhiz » Sun, Nov 02, 2025, 5:54 PM UTC

cbmuser wrote: post #438

thesuperbigfrog wrote: post #138

Earlier quoted context omitted.

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. Well, there are so many things were you could argue about the relevance of a userbase. If the size of a userbase would be the only argument, Valve could just drop support for the Linux userbase which is just 2-3% of their overall userbase.

Valve isn't a good example. They have strong Linux support so they can sell Steamdecks without licensing with Microsoft. Without their work on Proton, Steam effectively lives or dies by the will of Microsoft.

Re: Hard Rust requirements from May onward

#747

Post by larusso » Sun, Nov 02, 2025, 6:15 PM UTC

burntsushi wrote: post #723

larusso wrote: post #694

Earlier quoted context omitted.

Sorry. I will answer on this because I feel people got a bit hung up on the “new” thing. Might be a language barrier. I really understand the reasons why with backwards compatibility etc. The point I tried to make is that we really spend tons of time either to maintain software that where written or “born” 50 or so years ago or rewrite things in the same spirit. I mixed my comments wit the the security aspect which m…

Writing tools that are POSIX compatible doesn't mean one puts it on the pedestal of the "holy grail of OS design." I've certainly used POSIX to guide design aspects of things I build. Not because I think POSIX is the best. In fact, I think it's fucking awful and I very much dislike how some people use it as a hammer to whinge about portability. But POSIX is ubiquitous. So if you want your users to have less friction,…

Yes but GNU to put them under GPL. Or that was my understanding.

Re: Hard Rust requirements from May onward

#748

Post by throw10920 » Sun, Nov 02, 2025, 6:15 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…

This is a false dichotomy. There are memory-safe languages that are already proven and accepted in core Debian code that don't come with the downsides of Rust.

Re: Hard Rust requirements from May onward

#749

Post by hunterpayne » Sun, Nov 02, 2025, 6:48 PM UTC

testdelacc1 wrote: post #671

hunterpayne wrote: post #629

Earlier quoted context omitted.

My friend, the OP in this very thread has in multiple posts, made outright slanderous comments about C programmers. The reputation of the Rust community is very much the making of the Rust promoters. If you are seeing pushback, that's just the consequences of such behavior. I also notice that these language debates are very much generational. That has a few consequences. First is that older devs have thicker skin. Se…

Here, find the “null result” in this study by the Android team - Eliminating Memory Safety Vulnerabilities at the Source ( https://security.googleblog.com/2024/09/eliminating-memory-s... ). They stopped adding new memory unsafe code and they saw a dramatic drop in the number of memory safety vulnerabilities. They only write new code in Kotlin or Rust now. The Android team shipped a more secure operating system to bil…

> If you had you wouldn’t conflate memory safety with a lack of memory manipulation.

We are all aware of unsafe. We are also aware that all those assurances of safety go away in those circumstances.

This is cherry-picking. I didn't say all research papers, just most. This is a very specific circumstance. Under specific circumstances these ideas will work.

This example is one where the replaced code wasn't that old, on a very specific set of hardware and in a rather specific case. Its basically the ideal set of conditions for a rewrite. But there are plenty of cases where attempts to swap in Rust aren't being done in ideal conditions like this. I doubt switching to Rust is never a good idea. I also doubt switching to Rust is always a good idea.

PS The problem is partly the way you write. I criticize ideas. You criticize me. That's a big part of why you get pushback.

Re: Hard Rust requirements from May onward

#750

Post by richard_todd » Sun, Nov 02, 2025, 7:13 PM UTC

throwaway7356 wrote: post #677

richard_todd wrote: post #571

Earlier quoted context omitted.

There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to". And regard…

> my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever. That's not how open s…

ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences.

They certainly did NOT say "I'm replacing ipfirewall with ipchains in six months, and if your distro can't handle it you should sunset your distro."

It shouldn't be controversial to request a measured approach when making major changes to software lots of people depend on. That's part of the burden of working on important software. Note I'm not against apt or anything moving to rust.

edit: spelling