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

191–200 of 853 posts

Re: Rust in the kernel is no longer experimental

#191

Post by IshKebab »

ykonstant wrote: post #181

I need to check the rust parts of the kernel, I presume there is significant amounts of unsafe. Is unsafe Rust a bit better nowadays? I remember a couple of years ago people complained that unsafe is really hard to write and very "un-ergonomic".

I don't think unsafe Rust has gotten any easier to write, but I'd also be surprised if there was much unsafe except in the low-level stuff (hard to write Vec without unsafe), and to interface with C which is actually not hard to write.

Mostly Rust has been used for drivers so far. Here's the first Rust driver I found:

https://github.com/torvalds/linux/blob/2137cb863b80187103151...

It has one trivial use of `unsafe` - to support Send & Sync for a type - and that is apparently temporary. Everything else uses safe APIs.

Re: Rust in the kernel is no longer experimental

#192

Post by notachatbot123 »

tzury wrote: post #148

> Mike: rachel and i are no longer dating > > rachel: mike that's a horrible way of telling people we're married from the meme section on that page.

I was confused but then noticed the actual headline of the submitted page: "The end of the kernel Rust experiment"

Re: Rust in the kernel is no longer experimental

#193

Post by trinix912 »

tormeh wrote: post #137
jcranmer wrote: post #32

Earlier quoted context omitted.

There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran,…

A system only needs one programming language to be useful, and when there's only one it's basically always C.

A C compiler is also relatively easy to implement (compared to a Rust compiler) if you're making your own hobby OS with its own C compiler and libc.

Re: Rust in the kernel is no longer experimental

#194

Post by bigyabai »

jazzyjackson wrote: post #98
mustache_kimono wrote: post #90

Earlier quoted context omitted.

> Every system under the Sun has a C compiler... My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative. This is still the worst possible argument for C. If C persists in places no one uses, then who cares?

I think you didn't catch their drift C will continue to be used because it always has been and always will be available everywhere, not only places no one uses :/

> it always has been and always will be available everywhere

"Always has been" is pushing it. Half of C's history is written with outdated, proprietary compilers that died alongside their architecture. It's easy to take modern tech like LLVM for granted.

Re: Rust in the kernel is no longer experimental

#195

Post by wiz21c »

biorach wrote: post #145
markus_zhang wrote: post #11

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C

it is not straightforward in rust because the linked list is inherently tricky to implement correctly. Rust makes that very apparent (and, yeah, a bit too apparent).

I know, a linked list is not exactly super complex and rust makes that a bit tough. But the realisation one must have is this: building a linked list will break some key assumptions about memory safety, so trying to force that into rust is just not gonna make it.

Problem is I guess that for several of us, we have forgotten about memory safety and it's a bit painful to have that remembered to us by a compiler :-)

Re: Rust in the kernel is no longer experimental

#196

Post by biorach »

ViewTrick1002 wrote: post #164
biorach wrote: post #145

Earlier quoted context omitted.

There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C

Or just build a tested unsafe implementation as a library. For example the Linked List in the standard library. https://doc.rust-lang.org/src/alloc/collections/linked_list....

Yeah, if you need a linked list (you probably don't) use that. If however you are one of the very small number of people who need fine-grained control over a tailored data-structure with internal cross-references or whatnot then you may find yourself in a world where Rust really does not believe that you know what you are doing and fights you every step of the way. If you actually do know what you are doing, then Zig is probably the best modern choice. The TigerBeetle people chose Zig for these reasons, various resources on the net explain their motivations.

Re: Rust in the kernel is no longer experimental

#197

Post by flanked-evergl »

jenadine wrote: post #183

And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler. Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)

Can you please share more details about this?

Re: Rust in the kernel is no longer experimental

#198

Post by a96 »

mmooss wrote: post #53
sho_hn wrote: post #41

Earlier quoted context omitted.

I'm a bit wary if this is hiding an agist sentiment, though. I doubt most Rust developers were 'born into' the language, but instead adopted it on top of existing experience in other languages.

People can learn Rust at any age. The reality is that experienced people often are more hesitant to learn new things. I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to mak…

> experienced people often are more hesitant to learn new things

I believe the opposite. There's some kind of weird mentality in beginner/wannabe programmers (and HR, but that's unrelated) that when you pick language X then you're an X programmer for life.

Experienced people know that if you need a new language or library, you pick up a new language or library. Once you've learned a few, most of them aren't going to be very different and programming is programming. Of course it will look like work and maybe "experienced" people will be more work averse and less enthusiastic than "inexperienced" (meaning younger) people.

Re: Rust in the kernel is no longer experimental

#200

Post by einpoklum »

blintz wrote: post #65
drnick1 wrote: post #14

Earlier quoted context omitted.

Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?

Many organizations and environments will not switch themselves to LLVM to hamfist compiled Rust code. Nor is the fact of LLVM supporting something in principle means that it's installed on the relevant OS distribution.
Post reply on HN