Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

571–580 of 853 posts

Re: Rust in the kernel is no longer experimental

#571

Post by nicoburns »

jacquesm wrote: post #521
hollerith wrote: post #511

Earlier quoted context omitted.

Aren't large parts of a web browser and a runtime for a programming language also better written in Rust than in Go or Java?

I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available…

While it might be possible to get the performance required for a web rendering engine out of Java, I think you'd miserable writing Java in the style you'd need to get that kind of performance. And you'd likely still end up with issues around memory usage, app bundle size (remember that browsers ship to client devices), GC pauses, and integrating with the JavaScript engine.

Re: Rust in the kernel is no longer experimental

#572

Post by michaelmcmillan »

ls-a wrote: post #561

I never used linux because it was built using C++. Never have I cared what language the product was built it. The Rust community however wants you to use a product just because it's implemented in Rust, or atleast as one of the selling points. For that reason I decided to avoid any product that advertises using Rust as a selling point, as much as I can. Was planning to switch from Mac to a Linux machine, not anymore,…

Linux is written in C, my friend.

Re: Rust in the kernel is no longer experimental

#574

Post by simonask »

jacquesm wrote: post #507
eru wrote: post #297

Earlier quoted context omitted.

I guess in practice you'd want to have Rust installed as part of your local build and test environment. But I don't think you have to learn Rust any more (or any less) than you have to learn Perl or how the config script works. As long as you can detect if/when you break it, you can then either quickly pick up enough to get by (if it's trivial), or you ask around.

The proof of the pudding will be in the eating, the rust community better step up in terms of long term commitment to the code they produce because that is the thing that will keep this code in the kernel. This is just first base.

No matter how hard you try to paint it as such, Rust is not a tribe. This is such a weird characterization.

Rust contributions to the Linux kernel were made by individuals, and are very obviously subject to the exact same expectations as other kernel contributions. Maintainers have responsibilities, not “communities”.

Re: Rust in the kernel is no longer experimental

#575

Post by ndiddy »

Lariscus wrote: post #496
amiga386 wrote: post #426

Earlier quoted context omitted.

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.

Its strange to me that Linux dropped Itanium two years ago but they decided to keep supporting Alpha and PA-RISC.

Itanium was mainly dropped because it was impeding work in the EFI subsystem. EFI was originally developed for Itanium before being ported to other platforms, so the EFI maintainers had to build and test their changes to shared code on Itanium. They eventually decided that this wasn't worth the effort when there was basically nobody running modern Linux on Itanium besides a few hobbyists. I imagine that alpha and hppa will get dropped in the future if they ever also create an undue maintenance burden. There's more context here if you're interested: https://lwn.net/Articles/950466/

Re: Rust in the kernel is no longer experimental

#576

Post by estebank »

iurbwdj wrote: post #441
bayindirh wrote: post #411

Earlier quoted context omitted.

Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements. --- Yes. I remember that message. Also let's not forget what marcan said [0] [1]. In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing…

One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…

> What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp.

Could you point at a single quote from a member of the compiler team, current or former, that can be construed as hostility?

Re: Rust in the kernel is no longer experimental

#577

Post by aw1621107 »

viraptor wrote: post #499
josephg wrote: post #407

Earlier quoted context omitted.

> if the safe wrappers let you write arbitrary data to a PCIe network card’s registers Functions like that can and should be marked unsafe in rust. The unsafe keyword in rust is used both to say “I want this block to have access to unsafe rust’s power” and to mark a function as being only callable from an unsafe context. This sounds like a perfect use for the latter.

> Functions like that can and should be marked unsafe in rust. That's not how it works. You don't mark them unsafe unless it's actually required for some reason. And even then, you can limit that scope to a line or two in majority of cases. You mark blocks unsafe if you have to access raw memory and there's no way around it.

It is how it's supposed to work. `unsafe` is intended to be used on functions where the caller must uphold some precondition(s) in order to not invoke UB, even if the keyword is not strictly required to get the code to compile.

The general rule of thumb is that safe code must not be able to invoke UB.

Re: Rust in the kernel is no longer experimental

#578

Post by School-Cotton »

Xylakant wrote: post #452
bgwalter wrote: post #415

Earlier quoted context omitted.

I'm sure that submitting a PR to a Rust project to rewrite parts in Ada/SPARK would be met with great enthusiasm.

Why? It depends on what you want to replace, but the Rust project has a long history of using tools written in other languages. Python is used a lot in build tooling, bors-ng was written in Elixir, llvm is written in c, ... gcc-rs doesn't contain a lot of rust code either, it's purely other languages according to https://github.com/Rust-GCC/gccrs Fundamentally, if a tool is good and provides benefits then why not use…

It doesn't detract from your main point, but LLVM is written in C++, not C.

Re: Rust in the kernel is no longer experimental

#579

Post by estebank »

simonask wrote: post #574
jacquesm wrote: post #507

Earlier quoted context omitted.

The proof of the pudding will be in the eating, the rust community better step up in terms of long term commitment to the code they produce because that is the thing that will keep this code in the kernel. This is just first base.

No matter how hard you try to paint it as such, Rust is not a tribe. This is such a weird characterization. Rust contributions to the Linux kernel were made by individuals, and are very obviously subject to the exact same expectations as other kernel contributions. Maintainers have responsibilities, not “communities”.

Not only that, those individuals were already Linux kernel contributors. This is not an amorphous external group forcing their will on Linux, it's Linux itself choosing to use Rust.

Re: Rust in the kernel is no longer experimental

#580

Post by tremon »

weinzierl wrote: post #271

That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate. Removing the "experimental" tag is certainly a milestone to celebrate. I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no goin…

> I'm looking forward to distros shipping a default kernel with Rust support enabled

What does this mean? The kernel has no specific support for Rust userspace -- the syscall API does not suddenly change because some parts of the kernel are compiled with rustc.

Post reply on HN