Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

691–700 of 853 posts

Re: Rust in the kernel is no longer experimental

#691
post #588

Earlier quoted context omitted.

That's not the case. It's using Rust as a selling point. All the noise around using Rust is marketing. The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice

> It's using Rust as a selling point. That's just not true. Neither Linus Torvalds, nor the Linux Foundation, nor any major distro, nor anyone else who could conceivably be considered responsible for "marketing" Linux is saying you should use it because a small part of it is written in Rust. I just went to ubuntu.com and the word "rust" does not appear anywhere on the front page. So what are you talking about?

> Stay tuned for details in our Maintainers Summit coverage.

I can argue otherwise. Developer advocacy is a form of marketing (specially for a product traditionally targeted towards tech savvy people)

Re: Rust in the kernel is no longer experimental

#692
post #470

Earlier quoted context omitted.

That’s a reasonable position today, but what about in 20 years?

Do you know what technology will look like in 5 years? Or even 1 year?

cuz if you do you're about to make a lot of money gambling on or shorting AI...

Re: Rust in the kernel is no longer experimental

#693

Earlier quoted context omitted.

Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.

In normal user-mode rust, not running inside the kernel at all, you can open /dev/mem and write whatever you want to any process's memory (assuming you are root). This does not require "unsafe" at all. Another thing you can do from rust without "unsafe": output some buggy source code that invokes UB in a language like C to a file, then shell out to the compiler to compile that file and run it.

Sure, but those are non-central to what the program is doing. Writing to the wrong register offset and hosing main memory is a thing that happens when developing drivers (though usually it breaks obviously during testing).

Re: Rust in the kernel is no longer experimental

#694
post #128
post #30

Earlier quoted context omitted.

> very slow compilation times That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.

typescript transpilation to js is nearly instant, it's not comparable

Rust compilation is also almost instant, if you have a relatively small project.

It's only when you get very large projects that compilation time becomes a problem.

If typescript compilation speed wasn't a problem, then why would Microsoft put resources into rewriting the tyescript compiler in Go to make it faster[1]?

[1]: https://github.com/microsoft/typescript-go

Re: Rust in the kernel is no longer experimental

#695

Earlier quoted context omitted.

It's a bit like asking if there is any significant advantage to ICE motors over electric motors. They both have advantages and disadvantages. Every person who uses one or the other, will tell you about their own use case, and why nobody could possibly need to use the alternative. There's already applications out there for the "old thing" that need to be maintained, and they're way too old for anyone to bother with re…

Machine code: Yes. Punched cards: easy - every punch has the character it represents at the top of the card.

[deleted]

Re: Rust in the kernel is no longer experimental

#696

Happy to hear. We should embrace new things.

Why? New things are less stable, immature and require a lot of effort to understand. Don't get me wrong, rust in the kernel is good, because the memory safety and expressiveness it brings makes it worth it DESPITE the huge effort required to introduce it. But I disagree that new things are inherently good.

> I disagree that new things are inherently good.

New things aren't automatically good. But you don't get new things that are good without trying new things.

By avoiding new things, you're guaranteed to not experience less stable, immature, and confusing things. But also any new things that are good.

Re: Rust in the kernel is no longer experimental

#697
post #491

Earlier quoted context omitted.

It’s an interesting list from the perspective of what kind of project Linux is. Things like PA-RISC and Alpha were dead even in the 90s (thanks to the successful Itanium marketing push convincing executives not to invest in their own architectures), and SuperH was only relevant in the 90s due to the Dreamcast pushing volume. That creates an interesting dynamic where Linux as a hobbyist OS has people who want to suppo…

There was a time when it came to 64 bit support Alpha really was the only game in town where you could buy a server without adding a sixth zero to the bill. It was AMD, not Itanium that killed Alpha.

[deleted]

Re: Rust in the kernel is no longer experimental

#698

Earlier quoted context omitted.

I’ve done a decent amount of low level code - (never written a driver but I’m still young). The vast majority of it can be safe, and call into unsafe wrapped when needed. My experience is that a very very small amount of stuff actually needs unsafe and the only reason the unsafe C code is used is because it’s possible not because it’s necessary.

It is interesting how many very experienced programmers have not yet learned your lesson, so you may be young but you are doing very well indeed. Kudos.

Hah I’m not that young - it’s a figure of speech!

Re: Rust in the kernel is no longer experimental

#699

Earlier quoted context omitted.

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.

Yes. I was objecting to the parent poster's "can and should be" which sounds like they think people just randomly choose where to use the unsafe decoration.

The situation seems reminiscent of "using File::open to modify /proc/self/mem". It's safe to work with files, except there's this file that lets you directly violate memory safety.

Re: Rust in the kernel is no longer experimental

#700

Earlier quoted context omitted.

There's an allocation-free subset. https://www.swift.org/get-started/embedded/ Rust's approach is overkill, I think. A lot of reference counting and stuff is just fine in a kernel.

But at least a lot of tasks in a kernel would require something else than reference counting, unless it can be guaranteed that the reference counting is optimized away or something, right?

There are some allocations where it doesn't make sense for them to have multiple owners (strong references) but I wouldn't say it makes sense to think about it as being optimized away or not.
Post reply on HN