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

541–550 of 797 posts

Re: Hard Rust requirements from May onward

#541

Post by grg0 »

adwn wrote: post #459
throwawaymaths wrote: post #421

Earlier quoted context omitted.

How does this scheme of yours work with m/s and seconds. IIUC, rust would NOT let you do a type checked m/s * s => m, so using the type system for these kinds of games is silly and dangerous (I presume you would have to do the dumb thing and typeconvert to the same type -- e.g. (m) (speed * ((m/s) seconds)) to do multiplication which means you're inserting unscientific and reader-confusing type conversions all over t…

That's no problem in Rust. You can have a Speed type and a Time type, and define the multiplication operator over them to return a Length value. In fact, there's already a library which does exactly that, with tons of predefined SI units: https://docs.rs/uom/latest/uom/

And the exact same thing can be done in C++.

Re: Hard Rust requirements from May onward

#542

Post by kasabali »

steveklabnik wrote: post #522
samdoesnothing wrote: post #475

Earlier quoted context omitted.

That makes no sense. It was much longer than 10 years before people considered C to be tech debt for example. Idk if it will be 10 years exactly, but we are seeing better languages emerging (Swift 6, Mojo, probably others) that provide the same safety guarantees and performance/use case profiles as Rust, but are vastly more ergonomic and lovely to use. I fear Linux was hasty integrating Rust because it will likely pr…

You’re the one that said ten years.

You're the one who said "ten years since Rust 1.0"

Re: Hard Rust requirements from May onward

#543

Post by Dagonfly »

einr wrote: post #507
3eb7988a1663 wrote: post #209

Earlier quoted context omitted.

Debian just cut i386, Wikipedia says the i386 was discontinued in 2007. These systems are all of the same vintage, so it does not seem a huge leap to be culled from the support list. [0] https://en.wikipedia.org/wiki/I386

The actual Intel 80386 processor was discontinued in 2007, but the i386 architecture -- ia32, 32-bit x86 -- lived on for longer in the semi-mainstream (there were 32-bit Intel Atoms introduced to the market as late as 2012, AMD Geodes were sold until at least 2019, and I believe some VIA C3/C7 derivatives made it into the 2010s as well) and is in fact still in production to this day for the embedded and industrial ma…

All of those are i586 or i686 though right? AMD Geode LX is the only i586 CPU produced in the last 15 years.

Everything else is at least i686 and Rust has perfectly adequate i686 support.

Is there any major distro left with pre i686 support?

Re: Hard Rust requirements from May onward

#544

Post by woodruffw »

lpribis wrote: post #394
the__alchemist wrote: post #141

Earlier quoted context omitted.

Rust slaps on embedded too; I think that's one of its core competencies. But you have to do a lot of leg work for each piece of hardware because manufacturer support isn't there, and the OSS libs are usually not great. If your requirement is "Use only the most popular language in this domain", that's fine, but there's no point in evaluating or discussing other languages if so; the outcome is predetermined. I think th…

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.

Re: Hard Rust requirements from May onward

#545

Post by chris_wot »

RustSupremacist wrote: post #533
julian-klode wrote: post #497

Earlier quoted context omitted.

Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.

You have never been skilled at being considerate: https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

Christ that was handled badly.

Re: Hard Rust requirements from May onward

#546

Post by westurner »

From the mailing list on this: https://lists.debian.org/debian-devel/2025/10/msg00288.html :

  > Be careful.  Rust does not support some platforms well.[0]  ANything
  > that is not Tier 1 is not guaranteed to actually work.  And
  > architectures like m68k and powerpc are Tier 3.
  > 
  > [0] .
[ The rustc book > Platform Support: https://doc.rust-lang.org/beta/rustc/platform-support.html ]

[ The rustic book > Target Tier Policy: https://doc.rust-lang.org/beta/rustc/target-tier-policy.html... ]

  Thank you for your message.

  Rust is already a hard requirement on all Debian release
  architectures and ports except for alpha, hppa, m68k, and
  sh4 (which do not provide sqv).
Create a plan to add support for {alpha, hppa, m68k, and sh4,} targets to the Rust compiler

- 2.5pro: "Rust Compiler Target Porting Plan" https://gemini.google.com/share/b36065507d9d :

> [ rustc_codegen_gcc, libcore atomics for each target (m68k does not have support for 64-bit atomics and will need patching to libgcc helper functions), ..., libc, liballoc and libstd (fix std::thread, std::fs, std::net, std::sync), and then compiletest will find thousands of bugs ]

So, CI build hours on those actual but first emulated ISAs?

"Google porting all internal workloads to ARM, with help from GenAI" (2025) https://news.ycombinator.com/item?id=45691519

"AI-Driven Software Porting to RISC-V" (2025) https://news.ycombinator.com/item?id=45315314

"The Unreasonable Effectiveness of Fuzzing for Porting Programs" (2025) https://news.ycombinator.com/item?id=44311241 :

> A simple strategy of having LLMs write fuzz tests and build up a port in topological order seems effective at automating porting from C to Rust.

Re: Hard Rust requirements from May onward

#547

Post by remexre »

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.

Are there even close to 2% of Debian users using a DEC Alpha?

Re: Hard Rust requirements from May onward

#549

Post by jpgvm »

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.

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 code is usually 1/4th or smaller the original C code. If only implement what you need sometimes drivers can be less than 100 lines of Rust.

Re: Hard Rust requirements from May onward

#550

Post by richard_todd »

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, as is always evident by the complaints it causes. I love projects like Redox that try to do their own thing... why doesn't the rust community rally around projects like that and turn them into cve-free masterpieces that people will want to use?
Post reply on HN