Hard Rust requirements from May onward • Hacker News Board

Re: Hard Rust requirements from May onward

#371

Post by woodruffw » Sat, Nov 01, 2025, 6:12 PM UTC

cwzwarich wrote: post #278

gpm wrote: post #275

Earlier quoted context omitted.

Flagged for deliberately spreading disinformation under the name StopDisinfo. As this user is aware, rust has a specification https://github.com/rust-lang/fls , which they have previously commented on: https://news.ycombinator.com/item?id=44927141 (and which I probably wouldn't have remembered if not for the rather remarkable name they are saying false things under). Rust also has multiple compilers (rustc, mrustc, a…

The Rust specification you link is performative and only intended to satisfy requirements of certification processes. No one is actually using it to implement the language, as far as I am aware. There is other work on specifying Rust (e.g. the Unsafe Code Guidelines Working Group), but nothing approaching a real spec for the whole language. Honestly, it is probably impossible at this point; Rust has many layers of im…

“There’s a standard, but it’s performative” is a different argument than the top level one.

But even if we accept that, it doesn’t seem like a good comparative argument: anybody who has written a nontrivial amount of C or C++ has dealt with compiler-defined behavior or compiler language extensions. These would suggest that the C and C++ standards are “performative” in the same sense, but repeated claims about the virtues of standardization don’t seem compatible with accepting that.

Re: Hard Rust requirements from May onward

#372

Post by dathinab » Sat, Nov 01, 2025, 6:14 PM UTC

curt15 wrote: post #130

zozbot234 wrote: post #42

Earlier quoted context omitted.

m68k has a LLVM port already, so Rust can be implemented for that platform.[0] It would be nice to have LLVM backends for alpha, hppa and sh4 - these older architectures tend to be quite simple so a working LLVM has plenty of value as a reference and for educational use. (LLVM even used to have an in-tree DEC Alpha backend, though that was back in 2011 and not relevant to any version of Rust.) [0] Looks like there is…

Shouldn't the codegen_gcc project[1] theoretically allow Rust to target backends that only GCC supports? [1] https://github.com/rust-lang/rustc_codegen_gcc

yes and no

yes, from a pure code generation aspect

no, as all conditional-compiled platform specific code is missing.

So using it with #[no_core] should work (assuming the WIP part of the backend isn't a problem). But beyond that you have to first port libcore (should be doable) and then libstd (quite a bunch of work).

Re: Hard Rust requirements from May onward

#373

Post by gpm » Sat, Nov 01, 2025, 6:14 PM UTC

testdelacc1 wrote: post #65

DaSHacka wrote: post #37

Earlier quoted context omitted.

Or those annoying nagging "well, what if I don't have an X86_64 CPU that was made in the last five years?", to which obviously our response should be: "get different hardware LOL, closedwontfix"

Has Linux dropped support for older x86 CPUs?

Yeah, in... late 2012 https://lkml.org/lkml/2012/12/12/292

Re: Hard Rust requirements from May onward

#374

Post by hnthrowaway0315 » Sat, Nov 01, 2025, 6:16 PM UTC

ajkjk wrote: post #370

hnthrowaway0315 wrote: post #363

I don't care whether kernel developers want to use C or Rush or whatever. I judge the quality by using it in production. If it works well then I don't care how they are built.

How can you judge the security qualities of software by using it in production? You're surely not using it in the way someone looking for exploits would use it. Or I guess if you interpret this as a societal scale: we've collectively used C in production a lot, and look at all the security problems. Judgment completed. Quality is low.

I'm pretty sure many other companies are going to use it in production before mine does. I'll just ask around...

Re: Hard Rust requirements from May onward

#375

Post by jjmarr » Sat, Nov 01, 2025, 6:21 PM UTC

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.

That's literally what the C++ specification does. The reason for all the UB and implementation defined stuff is because 90s compilers disagreed on sizeof(int).

Re: Hard Rust requirements from May onward

#376

Post by dathinab » Sat, Nov 01, 2025, 6:22 PM UTC

mid-kid wrote: post #75

Wouldn't it make sense to wait for (or support) one of the rust-for-GCC ports to become viable? As far as I understand, rust in the kernel won't become mandatory either until it's supported by GCC, and as a boon, with multiple implementations you can be more certain that the language won't move as fast and break things anymore. There's already upstream rust support in GCC, so I don't reckon it's that far off from bei…

non of the listed architectures have official Debian support anymore

i.e. they are only still around because they haven't caused any major issues and someone bothered to fix them up from time to time on their own free time

so yes, you probably won't get them back in once they are out as long as a company doesn't shoulder the (work time) bill for it (and with it I mean long term maintenance more then the cost of getting them in)

but for the same reason they have little to no relevance when it comes to any future changes which might happen to get them kicked out (as long as no company steps up and shoulders the (work time) bill for keeping them maintained

Re: Hard Rust requirements from May onward

#377

Post by 0x000xca0xfe » Sat, Nov 01, 2025, 6:22 PM UTC

cmm11 wrote: post #136

0x000xca0xfe wrote: post #110

Earlier quoted context omitted.

What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.

Just annoys me that he calls features "crap" just because he likely doesn't use them personally and ends that post with a random sentence claiming such a version "increases the risk of drive-by attacks" with zero evidence. The developer explains the features aren't plugins and aren't even enabled by default. Arrogance from maintainers like this from within Debian is what will hurt it far more than any external entity…

Exactly, this rude and insulting behavior is why many people shy away from open source. Not everybody has the time and mental capacity to engage in ideological battles about software architecture.

We should really hold more value to keeping existing user setups working. Breakages are incredibly damaging and might very well have a bigger impact than insecure defaults.

Re: Hard Rust requirements from May onward

#378

Post by gmueckl » Sat, Nov 01, 2025, 6:23 PM UTC

Denvercoder9 wrote: post #354

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.

The only spec you need meet to get Perl or Python running on a new platform is the C spec. A compiler meeting that spec is enough to port and compile the interpreter for a new platform.

Re: Hard Rust requirements from May onward

#379

Post by mgh95 » Sat, Nov 01, 2025, 6:23 PM UTC

cmrdporcupine wrote: post #327

krater23 wrote: post #284

Earlier quoted context omitted.

I'm from embedded too. We tried to use rust in one of our projects and came to the conclusion that it makes no sense to convert our team from experiences C++ developers to beginner level Rust developers. Additionally to that, it was nearby impossible to control the amount of packages that come in with Cargo. We had for a small tool three versions of the same library as dependency in our binary. Additionally to that,…

You can absolutely use rustc without Cargo and there's frankly plenty of arguments for doing so in the context of embedded.

Large parts of tooling dependent on cargo; for examples, lsp, analyzer, etc.

Once you take out cargo, rusts development environment becomes quite poor.

Re: Hard Rust requirements from May onward

#380

Post by LexiMax » Sat, Nov 01, 2025, 6:23 PM UTC

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.

How do you think that C got specified?

Do you think that it was made up from whole cloth in the abstract machine and implemented later? No, it was based on the available implementations of its time.

On top of that, languages like Python do not have a specification and yet have multiple implementations.