APT Rust requirement raises questions • Hacker News Board

Re: APT Rust requirement raises questions

#171

Post by Aurornis » Tue, Nov 25, 2025, 4:17 PM UTC

geerlingguy wrote: post #5

I remembered reading about this news back when that first message was posted on the mailing list, and didn't think much of it then (rust has been worming its way into a lot of places over the past few years, just one more thing I tack on for some automation)... But seeing the maintainer works for Canonical, it seems like the tail (Ubuntu) keeps trying to wag the dog (Debian ecosystem) without much regard for the wide…

> I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers", but instead positioned only on the merits of the change.

The wording could have been better, but I don’t see it as a dig. When you look at the platforms that would be left behind they’re really, really old.

It’s unfortunate that it would be the end of the road for them, but holding up progress for everyone to retain support for some very old platforms would be the definition of the tail wagging the dog. Any project that starts holding up progress to retain support for some very old platforms would be making a mistake.

It might have been better to leave out any mention of the old platforms in the Rust announcement and wait for someone to mention it in another post. As it was written, it became an unfortunate focal point of the announcement despite having such a small impact that it shouldn’t be a factor holding up progress.

Re: APT Rust requirement raises questions

#172

Post by razighter777 » Tue, Nov 25, 2025, 4:17 PM UTC

geerlingguy wrote: post #5

I remembered reading about this news back when that first message was posted on the mailing list, and didn't think much of it then (rust has been worming its way into a lot of places over the past few years, just one more thing I tack on for some automation)... But seeing the maintainer works for Canonical, it seems like the tail (Ubuntu) keeps trying to wag the dog (Debian ecosystem) without much regard for the wide…

Agreed. I think that announcement was unprofessional.

This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change.

It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious.

This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable.

There's no clear cost-benefit analysis done for this change. Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse.

I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community.

Re: APT Rust requirement raises questions

#173

Post by fainpul » Tue, Nov 25, 2025, 4:17 PM UTC

ModernMech wrote: post #119

frizlab wrote: post #105

Earlier quoted context omitted.

On the contrary, Swift is very relevant on this subject. It has high feature parity with rust, with a much readable syntax.

But Swift is not "Kotlin for Rust" though, I can't see the connection at all. "Kotlin for Rust" would be a language that keeps you in the Rust ecosystem.

The commenter I replied to seems to like Kotlin. Swift is extremely close to Kotlin in syntax and features, but is not for the JVM. Swift also has a lot of similarities with Rust, if you ignore the fact that it has a garbage collector.

Re: APT Rust requirement raises questions

#174

Post by criddell » Tue, Nov 25, 2025, 4:18 PM UTC

dboon wrote: post #98

dralley wrote: post #17

Earlier quoted context omitted.

Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.

It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something yo…

> a pointer plus length

What would length represent? Bytes? Code points?

Anyway, I think what you are asking for already exists in the excellent ICU library.

And it's not a very easy thing to maintain. Unicode stuff changes more often than you might think and it can be political.

Re: APT Rust requirement raises questions

#175

Post by creata » Tue, Nov 25, 2025, 4:18 PM UTC

simonw wrote: post #71

simonask wrote: post #50

Earlier quoted context omitted.

What are you talking about? Rust’s function signature and type declaration syntaxes are extremely vanilla, unless you venture into some really extreme use cases with lots of lifetime annotations and generic bounds. I seriously don’t get it. fn add(a: i32, b: i32) -> i32 { … } Where’s the “Perl-esqueness”?

trait Handler { fn handle (&self, input: &'a str) -> Result ; } fn process_handler ( handler: Box , input: &'a str, ) -> Result { handler.handle(input) }

That's just a weird and unrealistic example, though. Like, why is process_handler taking an owned, boxed reference to something it only needs shared access to? Why is there an unnecessary 'a bound on handler?

In the places where you need to add lifetime annotations, it's certainly useful to be able to see them in the types, rather than relegate them to the documentation like in C++; cf. all the places where C++'s STL has to mention iterator and reference invalidation.

Re: APT Rust requirement raises questions

#176

Post by nofunsir » Tue, Nov 25, 2025, 4:19 PM UTC

inetknght wrote: post #104

fn-mote wrote: post #20

The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...] Another interesting, although perhaps tangential, criticism was that th…

> the "new solver" currently lacks a testsuite To borrow a phrase I recently coined: If it's not tested then it's not Engineered. You'd think that core tools would have proper Software Engineering behind them. Alas, it's surprising how many do not.

Unit tests does not make Software Engineering. That's simply part of the development phase, which should be the smallest phase out of all the phases involved in REAL Software Engineering, which is rarely even done these days, outside of DO-178 (et al) monotony. The entire private-to-public industry has even polluted upper management in defense software engineering into accepting SCRUM as somehow more desirable than the ability to effectively plan your requirements and execute without deviation. Yes it's possible, and yes it's even plausible. SWE laziness turns Engineers into developers. Running some auto-documentation script or a generic non-official block diagram is not the same as a Civil PE creating blueprints for a house, let alone a mile long bridge or skyscraper.

Re: APT Rust requirement raises questions

#177

Post by theoldgreybeard » Tue, Nov 25, 2025, 4:19 PM UTC

Rust developers are so dogmatic about their way being the best and only way that I just avoid it altogether. I've had people ask about Rust in issues/discussions in small hobby projects I released as open source - I just ban them immediately because there is no reasoning with them and they never give up. Open source terrorists.

Re: APT Rust requirement raises questions

#178

Post by Aurornis » Tue, Nov 25, 2025, 4:20 PM UTC

xscott wrote: post #165

movpasd wrote: post #84

Earlier quoted context omitted.

You might this blog post interesting, which argues that it's Rust semantics and not syntax that results in the noisiness, i.e.: it's intrinsic complexity: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html I found it reasonably convincing. For what it's worth, I found Rust's syntax quite daunting at first (coming from Python as well), but it only took a few months of continuous use to get used to it. I think…

I'm not sure which of the dozen Rust-syntax supporters I should reply to, but consider something like these three (probably equivalent) syntaxes: let mut a = Vec:: ::new(); let mut b = >::new(); let mut c = >::new(); let mut d: Vec = Vec::new(); Which one will your coworker choose? What will your other corworkers choose? This is day one stuff for declaring a dynamic array. What you really want is something like: let…

> Which one will your coworker choose? What will your other corworkers choose?

I don’t think I’ve ever seen the second two syntaxes anywhere.

I really don’t think this is a problem.

Re: APT Rust requirement raises questions

#179

Post by nixpulvis » Tue, Nov 25, 2025, 4:20 PM UTC

dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

Aside from async/await which I agree is somewhat janky syntaxtically, I'm curious what you consider to be janky. I think Rust is overall pretty nice to read and write. Patterns show up where you want them, type inference is somewhat limited but still useful. Literals are readily available. UFCS is really elegant. I could go on.

Ironically, I find Python syntax frustrating. Imports and list comprehensions read half backwards, variable bindings escape scope, dunder functions, doc comments inside the function, etc.

Re: APT Rust requirement raises questions

#180

Post by steveklabnik » Tue, Nov 25, 2025, 4:20 PM UTC

dboon wrote: post #98

dralley wrote: post #17

Earlier quoted context omitted.

Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.

It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something yo…

This is just a variation of the "skill issue" argument.

If it were correct, we wouldn't see these issues continue to pop up. But we do.