APT Rust requirement raises questions • Hacker News Board

Re: APT Rust requirement raises questions

#211

Post by pengaru » Tue, Nov 25, 2025, 4:40 PM UTC

adwn wrote: post #55

andsoitis wrote: post #34

Earlier quoted context omitted.

> The assumption here is that there exists an unambiguous C representation for all LLVM IR bitcode emitted by the Rust compiler. > To my knowledge, this isn’t the case. Tell us more?

For one, signed integer overflow is allowed and well-defined in Rust (the result simply wraps around in release builds), while it's Undefined Behavior in C. This means that the LLVM IR emitted by the Rust compiler for signed integer arithmetic can't be directly translated into the analogous C code, because that would change the semantics of the program. There are ways around this and other issues, but they aren't nec…

You guys seem to be assuming transpiling to C means it must produce C that DTRT on any random C compiler invoked any which way on the other side, where UB is some huge possibility space.

There's nothing preventing it from being some specific invocation of a narrow set of compilers like gcc-only of some specific version range with a set of flags configuring the UB to match what's required. UB doesn't mean non-deterministic, it's simply undefined by the standard and generally defined by the implementation (and often something you can influence w/cli flags).

Re: APT Rust requirement raises questions

#212

Post by MisterTea » Tue, Nov 25, 2025, 4:41 PM UTC

""and not be held back by trying to shoehorn modern software on retro computing devices""

Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire.

I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import duties in their country would be unaffordable. Thankfully they are also tinkering with 9front which has little to no issues with portability and still supports 32 bit.

Re: APT Rust requirement raises questions

#213

Post by [deleted] » Tue, Nov 25, 2025, 4:41 PM UTC

tcfhgj wrote: post #90

simonw wrote: post #71

Earlier quoted context omitted.

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

now show me an alternative syntax encoding the same information

[deleted]

Re: APT Rust requirement raises questions

#214

Post by duped » Tue, Nov 25, 2025, 4:42 PM UTC

hedora wrote: post #162

superxpro12 wrote: post #123

Earlier quoted context omitted.

As a c/c++ cmake user, cargo sounds like a utopia in comparison. It still amazes me that c/c++ package management is still spread between about 5 different solutions. IMO, the biggest improvement to C/C++ would be ISO defining a package manager a.la pip or uv or cargo. I'm so tired of writing cmake. just... tired.

People that don't understand make are destined to recreate it poorly, and there's no better example than cmake, imho. Here's my arc through C/C++ build systems: - make (copy pasted examples) - RTFM [1] - recursive make for all sorts of non-build purposes - this is as good as hadoop up to about 16 machines - autotools - cmake - read "recursive make considered harmful" [2] - make + templates Anyway, once you've underst…

cmake exists not because people didn't understand make, but because there was no one make to understand. The "c" is for "cross platform." It's a replacement for autoconf/automake, not a replacement for make.

> If I was going to try to improve on the state of the art

The state of the art is buck/bazel/nix/build2.

Re: APT Rust requirement raises questions

#215

Post by tremon » Tue, Nov 25, 2025, 4:42 PM UTC

reidrac wrote: post #12

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…

> 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, and sometimes the Canonical employees were the voice of reason (e.g. that's how I remember Steve Langasek).

I'm sure some will point out that each example above was just an isolated incident, but I perceive a growing pattern of incidents. There was a time when Debian proudly called itself "The Universal Operating System", but I think that hasn't been true for a while now.

Re: APT Rust requirement raises questions

#216

Post by e12e » Tue, Nov 25, 2025, 4:43 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…

> It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years.

Maybe Ada, D or Nim might qualify?

Re: APT Rust requirement raises questions

#217

Post by aaronblohowiak » Tue, Nov 25, 2025, 4:43 PM UTC

MisterTea wrote: post #212

""and not be held back by trying to shoehorn modern software on retro computing devices"" Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire. I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import dutie…

Rust works fine on 32 bit, (and 16 bit) that’s not what they mean…

Re: APT Rust requirement raises questions

#218

Post by chc4 » Tue, Nov 25, 2025, 4:44 PM UTC

MisterTea wrote: post #212

""and not be held back by trying to shoehorn modern software on retro computing devices"" Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire. I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import dutie…

No one is using an Alpha, Motorola 680x0, PA-RISC, or SuperH computer because that's the only thing they can afford. Rust supports 32bit x86.

Re: APT Rust requirement raises questions

#219

Post by quux » Tue, Nov 25, 2025, 4:44 PM UTC

MisterTea wrote: post #212

""and not be held back by trying to shoehorn modern software on retro computing devices"" Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire. I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import dutie…

Looking at the list of affected architectures: Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4) I think these are much much more likely to be run by enthusiasts than someone needing an affordable computer.

Re: APT Rust requirement raises questions

#220

Post by ForHackernews » Tue, Nov 25, 2025, 4:44 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…

I mean... Pentium Pro is 30 years old at this point. I don't think it's unreasonable that modern software isn't targeting those machines.