APT Rust requirement raises questions • Hacker News Board

Re: APT Rust requirement raises questions

#271

Post by xscott » Tue, Nov 25, 2025, 5:15 PM UTC

bobbylarrybobby wrote: post #202

xscott wrote: post #165

Earlier quoted context omitted.

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…

I've only ever seen `a` and `d`. Personally I prefer `a`. The only time I've seen `c` is for trait methods like ` >::func`. Noisy? I guess. Not sure how else this could really be written.

Fwiw, I didn't go looking for obscure examples to make HN posts. I've had three rounds of sincerely trying to really learn and understand Rust. The first was back when pointer types had sigils, but this exact declaration was my first stumbling block on my second time around.

The first version I got working was `d`, and my first thought was, "you're kidding me - the right hand side is inferring it's type from the left?!?" I didn't learn about "turbo fish" until some time later.

Re: APT Rust requirement raises questions

#272

Post by mschuster91 » Tue, Nov 25, 2025, 5:17 PM UTC

tremon wrote: post #215

reidrac wrote: post #12

Earlier quoted context omitted.

> As an end user, it doesn't concern me too much ... It doesn't concern me neither, but there's some attitude here that makes me uneasy. This could have been managed better. I see a similar change in the future that could affect me, and there will be precedent. Canonical paying Devs and all, it isn't a great way of influencing a community.

I agree. It's sad to see maintainers take a "my way or the highway" approach to package maintenance, but this attitude has gradually become more accepted in Debian over the years. I've seen this play before, with different actors: gcc maintainers (regarding cross-bootstrapping ports), udev (regarding device naming, I think?), systemd (regarding systemd), and now with apt. Not all of them involved Canonical employees,…

> It's sad to see maintainers take a "my way or the highway" approach to package maintenance, but this attitude has gradually become more accepted in Debian over the years.

It's frankly the only way to maintain a distribution relying almost completely on volunteer work! The more different options there are, the more expensive (both in terms of human cost, engineering time and hardware cost) testing gets.

It's one thing if you're, say, Red Hat with a serious amount of commercial customers, they can and do pay for conformance testing and all the options. But for a fully FOSS project like Debian, eventually it becomes unmaintainable.

Additionally, the more "liberty" distributions take in how the system is set up, the more work software developers have to put in. Just look at autotools, an abomination that is sadly necessary.

Re: APT Rust requirement raises questions

#273

Post by dontlaugh » Tue, Nov 25, 2025, 5:18 PM UTC

tyfon wrote: post #204

I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would a…

Surely retro hardware is fine with retro software.

Re: APT Rust requirement raises questions

#274

Post by vablings » Tue, Nov 25, 2025, 5:19 PM UTC

travisgriggs wrote: post #243

razighter777 wrote: post #172

Earlier quoted context omitted.

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…

> 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. Thanks for this. I know intellectually, that there are sane/pragmatic people who appreciate Rust. But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel s…

>I know intellectually, that there are sane/pragmatic people who appreciate Rust.

For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod.

for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly and performance will probably exceed the original implementation in some cases since concurrency is a cake-walk.

The whole re-write it in rust largely stemmed from the idea that if you have a program in C and a program in Rust then the program in rust is "automatically" better which is often the case. The exception is very large battle tested projects with custom tooling in place to ensure the issues that make C/C++ a nightmare are somewhat reduced. Rust ships with the borrow checker by default meaning logically its like for like.

In the real world it is not always the case there are still plenty of opportunity for straight up logic bugs and crashes (See cloudflare saga) that are completely just due to bad programming practices.

Rust is the nail and the hammer, but you can still hit your finger if you don't know how to swing it properly

FYI for the purpose of disclosing bias I am one of the few "rust first" developers. I learned the language in 2021, and it was the first "real" programming language I learned how to use effectively. Any attempts I have had to dive into other languages have been short lived and incredibly frustrating because rust is a first-class experience in how to make a systems programming language

Re: APT Rust requirement raises questions

#275

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

dragonwriter wrote: post #270

steveklabnik wrote: post #260

Earlier quoted context omitted.

The issue though is that this isn't a solvable "problem". This is how programming languages' syntax work. It's like saying that C's if syntax is bad because these are equivalent: if (x > y) { if ((x > y)) { if (((x) > (y))) { Yes, one of your co-workers may write the third form. But it's just not possible for a programming language to stop this from existing, or at least, maybe you could do it, but it would add a ton…

Well, the solution usually isn't in syntax, but it often is solved by way of code formatters, which can normalize the syntax to a preferred form among several equivalent options.

I certainly would support rustfmt turning those redundant forms into the simpler one.

Re: APT Rust requirement raises questions

#276

Post by grayhatter » Tue, Nov 25, 2025, 5:21 PM UTC

cogman10 wrote: post #252

tyfon wrote: post #204

I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would a…

This sounds like it's fun. However, I have to ask, why should the linux world cater to supporting 30 year old systems? Just because it scratches an itch? You can grab a $150 NUC which will run circles around this dual pentium pro system while also using a faction of the power. You obviously have to do a lot of extra work, including having a second system, just to keep this old system running. More work than it'd take…

> You can grab a $150 NUC

I grew up without money, it makes me laugh when I read comments like this. You can just, yeah when you're fortunate enough to have a strong support system; you can.

My understanding is that the systems are not meaningfully common, and are hobbyist archs. But the idea that dropping support is fine because you can just throw money at it is so incredibly divorced from reality that I actually feel bad for anyone that believes this.

I deeply believe that if you don't like what a maintainer of FOSS code has done, you should fork the project. Admittedly that's a very onerous suggestion. But more important than that, you should help people when you can. If you're deciding to drop support for a bunch of people because it makes your job easier or simpler, when you don't need to. You're the bad guy in the story. That's the way this announcement has been written, and most reasonable people object to that kind of behavior. Selfishness should feel a bit offensive to everyone.

Re: APT Rust requirement raises questions

#277

Post by stodor89 » Tue, Nov 25, 2025, 5:21 PM UTC

Havoc wrote: post #203

leoh wrote: post #87

I hate learning new things. It sucks. Also, I hate things that make my knowledge of C++ obsolete. I hate all the people that are getting good at rust and are threatening to take away my job. I hate that rust is a great leveler, making all my esoteric knowledge of C++ that I have been able to lord over others irrelevant. I hate that other people are allowed to do this to me and to do whatever they want, like making th…

Think tech space isn’t for you if you hate learning new things.

It's sarcasm.

Re: APT Rust requirement raises questions

#278

Post by Aurornis » Tue, Nov 25, 2025, 5:22 PM UTC

steveklabnik wrote: post #254

Aurornis wrote: post #240

Earlier quoted context omitted.

> 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. I’m Normally I’d agree, but the ports in question are really quite old and obscure. I don’t think anything would have changed with an even longer timeline. I think the best move would have been to announce deprecation of thos…

Those ports were never official, and so aren't being deprecated. Nothing changes about Debian's support policies with this change. EDIT: okay so I was slightly too strong: some of them were official as of 2011, but haven't been since then. The main point that this isn't deprecating any supported ports is still accurate.

That’s helpful info, but I don’t think it will change any of the minds that are angry about what they see as Rust taking something away from someone.

It’s the way the two actions were linked that caused the controversy.

Re: APT Rust requirement raises questions

#279

Post by kevin_thibedeau » Tue, Nov 25, 2025, 5:23 PM UTC

razighter777 wrote: post #172

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…

> Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for

This will be an impediment for new architectures in the future. Instead of just "builds with gcc" we would need to wait for Rust support.

Re: APT Rust requirement raises questions

#280

Post by miladyincontrol » Tue, Nov 25, 2025, 5:24 PM UTC

Aurornis wrote: post #171

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…

Not just really, really old, but they in fact have long since been depreciated in any semblance of official support.

I get the friction especially for younger contributors, not that this is the case here. However there are architectures that havent even received a revision in their lifetime which old heads will take as personal slights for which heads must roll when presented with even the slightest of inconvenience for their hobbyist port.