Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

421–430 of 853 posts

Re: Rust in the kernel is no longer experimental

#421
post #405

Earlier quoted context omitted.

[flagged]

Going off on the name makes your entire question and argument subjective and useless in a constructive discussion.

In-general it seems that Rust proponents want ease and modernity to replace the ability to do the same in C better, with more control and intent, and with better results.

Rust is less tight. That’s fine for an application, but the kernel is used by everyone who uses Linux.

Rustians disparage C because it doesn’t have Rust behavior.

Why must the kernel have Rust behavior?

Re: Rust in the kernel is no longer experimental

#424
post #408

Earlier quoted context omitted.

If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase. Rust isn’t an invading tribe. It’s just a tool.

> If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase. That’s “appeal to authority” fallacy.

Pointing out that something was iterated upon and adopted in the place it was introduced is now a fallacy, amazing.

Re: Rust in the kernel is no longer experimental

#425

Does this mean that all architectures that Linux supports but Rust doesn't are straight in the bin?

Which ones would that be?

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html, cleaned them up so they can be compared like for like and then put them into this python script:

  linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon",
    "loongarch", "m68k", "microblaze", "mips", "mips64", "nios2",
    "openrisc", "parisc", "powerpc", "powerpc64", "riscv",
    "s390", "s390x", "sh", "sparc", "sparc64", "x86", "x86_64",
    "xtensa" }
  
  rust = { "arm", "aarch64", "amdcgn", "avr", "bpfeb", "bpfel",
    "csky", "hexagon", "x86", "x86_64", "loongarch", "m68k",
    "mips", "mips64", "msp430", "nvptx", "powerpc", "powerpc64",
    "riscv", "s390x", "sparc", "sparc64", "wasm32", "wasm64",
    "xtensa" }
  
  print(f"Both: {linux.intersection(rust)}")
  print(f"Linux, but not Rust: {linux.difference(rust)}")
  print(f"Rust, but not Linux: {rust.difference(linux)}")
Which yields:

Both: {'aarch64', 'xtensa', 'sparc', 'm68k', 'mips64', 'sparc64', 'csky', 'riscv', 'powerpc64', 's390x', 'x86', 'powerpc', 'loongarch', 'mips', 'hexagon', 'arm', 'x86_64'}

Linux, but not Rust: {'nios2', 'microblaze', 'arc', 'openrisc', 'parisc', 's390', 'alpha', 'sh'}

Rust, but not Linux: {'avr', 'bpfel', 'amdcgn', 'wasm32', 'msp430', 'bpfeb', 'nvptx', 'wasm64'}

Personally, I've never used a computer from the "Linux, but not Rust" list, although I have gotten close to a DEC Alpha that was on display somewhere, and I know somebody who had a Sega Dreamcast (`sh`) at some point.

Re: Rust in the kernel is no longer experimental

#426

Does this mean that all architectures that Linux supports but Rust doesn't are straight in the bin?

Which ones would that be?

https://lwn.net/Articles/1045363/

> Rust, which has been cited as a cause for concern around ensuring continuing support for old architectures, supports 14 of the kernel's 20-ish architectures, the exceptions being Alpha, Nios II, OpenRISC, PARISC, and SuperH.

Re: Rust in the kernel is no longer experimental

#427
post #323

Earlier quoted context omitted.

m68k Linux is supported by Rust, even in the LLVM backend. Rust also has an experimental GCC-based codegen backend (based on libgccjit (which isn't used as a JIT)). So platforms that don't have either LLVM nor recent GCC are screwed.

how on earth is linux being compiled for platforms without a GCC? additionally, I believe the GCC backend is incomplete. the `core` library is able to compile, but rust's `std` cannot be.

>nor recent GCC are screwed.

Not having a recent GCC and not having GCC are different things. There may be architectures that have older GCC versions, but are no longer supported for more current C specs like C11, C23, etc.

Re: Rust in the kernel is no longer experimental

#428
post #421
post #405

Earlier quoted context omitted.

Going off on the name makes your entire question and argument subjective and useless in a constructive discussion.

In-general it seems that Rust proponents want ease and modernity to replace the ability to do the same in C better, with more control and intent, and with better results. Rust is less tight. That’s fine for an application, but the kernel is used by everyone who uses Linux. Rustians disparage C because it doesn’t have Rust behavior. Why must the kernel have Rust behavior?

> Rustians disparage C

No, the 50+ years of ridiculously unavoidable memory corruption errors have done more to disparage C than anyone working in another language.

Re: Rust in the kernel is no longer experimental

#429

Earlier quoted context omitted.

You can write slop in any language. And good software for that matter.

I've never met anything written in JS/Typescript that I would call "well written".

I have. I personally really enjoy the recent crop of UI frameworks built for the web. Tools like Solidjs or Svelte.

Whatever your thoughts are about react, the JavaScript community that has been the tip of the spear for experimenting with new ways to program user interfaces. They’ve been at it for decades - ever since jQuery. The rest of the programming world are playing catchup. For example, SwiftUI.

VSCode is also a wonderful little IDE. Somehow much faster and more stable than XCode, despite being built on electron.

Re: Rust in the kernel is no longer experimental

#430

Earlier quoted context omitted.

The Unix/C people wrote their own kernel in the 1970s instead of invading an existing one.

If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase. Rust isn’t an invading tribe. It’s just a tool.

The "provide value" argument can be used for anything. Modern software politics and foundation sponsorship pressure are so complex that this argument may not even be true.

It may be true in this case, but certainly you have seen corporate bloat being added to "open" source projects before.

Post reply on HN