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

351–360 of 797 posts

Re: Hard Rust requirements from May onward

#351

Post by baobun »

superkuh wrote: post #157

Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, wil…

Debian still has its policies which means your use-case shouldn't be affected by this.

The rustc version will be fixed for compaibility at every release and all rust dependencies must be ported to apts.

In the debian context, the burden imposed by rust churn and "cargo hell" falls on debian package maintainers.

Re: Hard Rust requirements from May onward

#352

Post by onli »

brainwad wrote: post #293
onli wrote: post #166

Earlier quoted context omitted.

I wouldn't see it that way. First, Debian is not a distro where users have to compile their software. The packages contain binaries, the compilation is already done. The instability of Rust would not affect users in any way. And second, as a developer, I never had a more unpleasant language to work with than Rust. The borrow checker back then was abysmal. Rust is not about developer happiness - Ruby is - but its memo…

> The instability of Rust would not affect users in any way. Sure it would. Suppose a rust-based package has a security bug. Upstream has fixed it, but that fix depends on some new rust language feature that the frozen version of rust in Debian doesn't have yet.

Then the responsible Debian maintainer would backport that fix, as they have done in other languages for decades. Really, that's not user facing. It's a possible hassle for the maintainers and developers, which might be bad enough, but not a problem for users.

Re: Hard Rust requirements from May onward

#353

Post by dathinab »

uecker wrote: post #7
justinclift wrote: post #6

One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html > 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). Wonder what this means for those architectures then?

They are of no commercial interest to Ubuntu.

more relevant they are all "unofficial" supported architectures and non in a "might get official support" context, so they all have been of very limited interest of Debian as a whole for quite a while

Re: Hard Rust requirements from May onward

#354

Post by Denvercoder9 »

StopDisinfo910 wrote: post #261

Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.

Perl has been a hard dependency of the base system since forever and it doesn't have a specification nor more than one interpreter.

Re: Hard Rust requirements from May onward

#355

Post by vlovich123 »

smithkl42 wrote: post #260
OptionOfT wrote: post #231

Earlier quoted context omitted.

What is the concern with LLVM? I'm asking because I genuinely don't know.

I think the issue he's pointing at is that LLVM is itself written in C++ - so the entire "trusted" Rust toolchain depends on trusting a huge C++ app.

Thankfully the “trust” you need out of a compiler is very very different. It would be closer to claiming you need to compile it on a Rust OS too because you’re trusting a large C/C++ app.

Separation of concerns solves this because the compiler has minimal impact on the trustedness of the code the Rust compiler generates. Indeed, one would expect that all the ways that the LLVM compiler fails are ways any Rust implementation would fail too - by generating the wrong code which is rarely if ever due to memory safety or thread safety issues. There may be other reasons to write the compiler backend in Rust but I wouldn’t put the trust of compiled Rust code as anywhere near the top of reasons to do that.

Re: Hard Rust requirements from May onward

#356

Post by dgsii »

arccy wrote: post #324
hypeatei wrote: post #273

Earlier quoted context omitted.

Ferrous Systems donated their language specification ("Ferrocene") to the Rust foundation[0] who is working on integrating it but that takes time, obviously. 0: https://rustfoundation.org/media/ferrous-systems-donates-fer...

Their spec just happens to describe whatever the compiler decided to implement, it's not a source of truth.

I don’t think it’s a fair argument to criticize a spec because it’s derived from an implementation. If anything it shows how the spec can be practically applied.

Re: Hard Rust requirements from May onward

#357

Post by loeg »

3eb7988a1663 wrote: post #209
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…

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

Yeah, and you can still run i386 binaries on widely available amd64 CPUs. So this is an even stronger argument for killing these other obsolete platforms.

Re: Hard Rust requirements from May onward

#358

Post by gpm »

mattbee wrote: post #333
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…

The Fil-C project ( https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.

I really like the idea of Fil-C for derisking legacy code, but

- It's not an option for debian core infrastructure until it supports at least the same platforms debian does (arm, riscv, etc) and it currently only supports x86_64.

- It doesn't turn C into a modern language, since it looks like there's active development here getting the productivity benefits of moving away from C is likely still worth it.

Re: Hard Rust requirements from May onward

#359

Post by uecker »

Klonoar wrote: post #337
uecker wrote: post #289

Earlier quoted context omitted.

The point of freedom in software is certainly that I can create my own fork. And individual projects a maintainer can certainly do what he wants. But it is still worrying if in community projects such as Debian when decisions that come with a cost to some part of the community are pushed through without full consensus. It would be certainly not the first time. systemd was similar and for similar reasons (commercial i…

> are pushed through without full consensus You describe it that way, but that's not how the world in general works in practice. You do things based on majority.

No, this is not how you do things in a functioning community. You do things based on societal contracts that also protect the interests of minorities.

Re: Hard Rust requirements from May onward

#360

Post by teunispeters »

Surac wrote: post #94

I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready

when rust passes MISRA (or has its own MISRA rules), that may change. Call that a nice goal.

(I similarly have yet to see a single convincing argument to try to fight past the awkward, verbose and frustrating language that is rust).

Post reply on HN