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

The Register: Rust for Linux maintainer steps down

theregister.com

Post reply on HN
Print view View original

11–20 of 28 posts

Re: The Register: Rust for Linux maintainer steps down

#11

Post by pornel »

Y_Y wrote: post #3

> I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production-ready for some use cases within a few years. I presume @ddevault knows about Redox, so I'm surprised he didn't mention it in this context. In any case I thought it was an insightful remark. The more I learn about the politics of big projects, the more I believe in flowing around…

To me Drew's article is a "bless your heart" answer that tells Rust users to go away, and keep themselves busy with something that nobody else will care about.

Re: The Register: Rust for Linux maintainer steps down

#12

Post by Y_Y »

deng wrote: post #9
laymansterms wrote: post #8

Earlier quoted context omitted.

He actually did mention it if you look at the blog post his quote comes from. He's specifically calling for a Linux-ABI-compatible rust kernel that just re-implements things as they were rather than trying to delve into new researchy OS concepts like what Redox does.

Writing a Linux-ABI-compatible kernel in Rust will lead to a kernel no one uses. What would be the advantage of such a kernel? It would be much, much slower for many workloads and only be interesting to Rust hackers. In "Linux the OS", we are stuck with the "Linux the kernel", and Drew knows this very well. You will never catch up with the years of development that went into it. So if you want Rust in the kernel of "…

> This approach can work, see for instance the history of PREEMPT-RT.

Good point, I note that realtime preemption has been in the works for more than twenty years, but (surprisingly) still isn't in mainline. On the other hand it's widely used and available and has caused lots of changes upstream already.

https://lwn.net/Articles/951337/

Re: The Register: Rust for Linux maintainer steps down

#13

Post by deng »

Y_Y wrote: post #12
deng wrote: post #9

Earlier quoted context omitted.

Writing a Linux-ABI-compatible kernel in Rust will lead to a kernel no one uses. What would be the advantage of such a kernel? It would be much, much slower for many workloads and only be interesting to Rust hackers. In "Linux the OS", we are stuck with the "Linux the kernel", and Drew knows this very well. You will never catch up with the years of development that went into it. So if you want Rust in the kernel of "…

> This approach can work, see for instance the history of PREEMPT-RT. Good point, I note that realtime preemption has been in the works for more than twenty years, but (surprisingly) still isn't in mainline. On the other hand it's widely used and available and has caused lots of changes upstream already. https://lwn.net/Articles/951337/

PREEMPT-RT is almost completely in mainline. As your linked article says, pretty much the last issue is printk. You can download the last patch here, it's not much anymore:

https://cdn.kernel.org/pub/linux/kernel/projects/rt/6.11/

And this is the only way you'll get large changes like these into the kernel: slow and steady.

Re: The Register: Rust for Linux maintainer steps down

#14

Post by pornel »

incrudible wrote: post #4
mustache_kimono wrote: post #2

> [Filho said]: "Almost four years into this, I expected we would be past tantrums from respected members of the Linux kernel community. I just ran out of steam to deal with them, as I said in my email." I'm not surprised Wedson feels this way. It's irresponsible to leave devs out to dry like this. If the Linux Foundation hires Linus and others and pays them gobs and gobs of dough, they should lead. If you set the te…

Rust in the kernel is still an experiment, you can't lead in a direction that doesn't exist. The "nontechnical nonsense" is actually the more important and more difficult part of software development. My feeling about Rust is that it's a playground language where many ideas are tried and insights can be formed, but it needs to be distilled down to something simpler with a stable ABI to be used for something like Linu…

> My feeling about Rust is that it's a playground language where many ideas are tried and insights can be formed

No, from the very beginning this has been an explicit non-goal of Rust.

http://venge.net/graydon/talks/intro-talk-2.pdf

Rust has used reaserch from 80s and 90s languages. The result may seem novel because the programming language theory and languages that Rust copied are not well known among systems programmers. The ideas are old, Rust added the polish and packaging of the features with a focus on practical non-reaserch use.

Rust isn't that new any more. 1.0 has been released almost a decade ago.

Re: The Register: Rust for Linux maintainer steps down

#15

Post by anonfordays »

pornel wrote: post #14
incrudible wrote: post #4

Earlier quoted context omitted.

Rust in the kernel is still an experiment, you can't lead in a direction that doesn't exist. The "nontechnical nonsense" is actually the more important and more difficult part of software development. My feeling about Rust is that it's a playground language where many ideas are tried and insights can be formed, but it needs to be distilled down to something simpler with a stable ABI to be used for something like Linu…

> My feeling about Rust is that it's a playground language where many ideas are tried and insights can be formed No, from the very beginning this has been an explicit non-goal of Rust. http://venge.net/graydon/talks/intro-talk-2.pdf Rust has used reaserch from 80s and 90s languages. The result may seem novel because the programming language theory and languages that Rust copied are not well known among systems progra…

>Rust isn't that new any more. 1.0 has been released almost a decade ago.

And yet I have to use nightly to get practically anything to work.

Re: The Register: Rust for Linux maintainer steps down

#16

Post by steveklabnik »

anonfordays wrote: post #15
pornel wrote: post #14

Earlier quoted context omitted.

> My feeling about Rust is that it's a playground language where many ideas are tried and insights can be formed No, from the very beginning this has been an explicit non-goal of Rust. http://venge.net/graydon/talks/intro-talk-2.pdf Rust has used reaserch from 80s and 90s languages. The result may seem novel because the programming language theory and languages that Rust copied are not well known among systems progra…

>Rust isn't that new any more. 1.0 has been released almost a decade ago. And yet I have to use nightly to get practically anything to work.

What features do you rely on? This is effectively the opposite of my experience, which is why I am curious: even our embedded OS at work is almost free of nightly features, and everything higher in the stack has been on stable for a long time. Always interested in learning how experiences differ!

Re: The Register: Rust for Linux maintainer steps down

#17

Post by anonfordays »

steveklabnik wrote: post #16
anonfordays wrote: post #15

Earlier quoted context omitted.

>Rust isn't that new any more. 1.0 has been released almost a decade ago. And yet I have to use nightly to get practically anything to work.

What features do you rely on? This is effectively the opposite of my experience, which is why I am curious: even our embedded OS at work is almost free of nightly features, and everything higher in the stack has been on stable for a long time. Always interested in learning how experiences differ!

>is almost free of nightly features

So it's not free of said features and you have to use nightly?

>What features do you rely on?

Several of these highlighted here:https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...

Something like 30% of users were on nightly a few years ago. Not sure if that's still true, but it is for me.

Re: The Register: Rust for Linux maintainer steps down

#18

Post by steveklabnik »

anonfordays wrote: post #17
steveklabnik wrote: post #16

Earlier quoted context omitted.

What features do you rely on? This is effectively the opposite of my experience, which is why I am curious: even our embedded OS at work is almost free of nightly features, and everything higher in the stack has been on stable for a long time. Always interested in learning how experiences differ!

>is almost free of nightly features So it's not free of said features and you have to use nightly? >What features do you rely on? Several of these highlighted here: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve... Something like 30% of users were on nightly a few years ago. Not sure if that's still true, but it is for me.

Yes, for that OS we’re using asm_const, which is almost stable, naked functions, and used_with_arg, which is linker related. We also use array_methods but that could be polyfilled, if the other three were stable.

Re: The Register: Rust for Linux maintainer steps down

#19

Post by aeadio »

woodPurchase wrote: post #7

>That remark is a response to a comment on the video that, according to Filho, came from Linux kernel maintainer Ted Ts'o: "Here's the thing, you're not going to force all of us to learn Rust." >The video depicts resistance to Filho's request to get information to statically encode file system interface semantics in Rust bindings, as a way to reduce errors. Ts'o's objection is that C code will continue to evolve, and…

> Ah, yes. Drew DeVault. The expert in ... developing 30M LOC OS kernels with billions of dollars on R&D investment in a few years with a small team in an experimental language. "Just make Linux 2", it's so simple, why didn't we think of this?!

This is an unusual take considering Drew DeVault actually does have experience developing new kernels [1] in experimental languages [2].

Drew's own post [3] (which the linked article references) doesn't downplay the effort involved in developing a kernel. But you're definitely overplaying it. 30M SLOC in the Linux kernel is largely stuff like device drivers, autogenerated headers, etc. While the Linux kernel has a substantial featureset, those features comprise a fraction of that LOC count.

Meanwhile, what Drew's suggesting is a kernel that aims for ABI compatibility. That's significantly less work than a full drop-in replacement, since it doesn't imply every feature is supported.

Not to mention, some effort could probably be put into developing mechanisms to assist in porting Linux device drivers and features over to such a replacement kernel using a C interface boundary that lets them run the original unsafe code as a stopgap.

[1] https://sr.ht/~sircmpwn/helios/

[2] https://harelang.org

[3] https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...

Re: The Register: Rust for Linux maintainer steps down

#20

Post by pornel »

anonfordays wrote: post #17
steveklabnik wrote: post #16

Earlier quoted context omitted.

What features do you rely on? This is effectively the opposite of my experience, which is why I am curious: even our embedded OS at work is almost free of nightly features, and everything higher in the stack has been on stable for a long time. Always interested in learning how experiences differ!

>is almost free of nightly features So it's not free of said features and you have to use nightly? >What features do you rely on? Several of these highlighted here: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve... Something like 30% of users were on nightly a few years ago. Not sure if that's still true, but it is for me.

crates.io sees about 13% of requests from nightly compilers, although that may be biased by CI tests that just check for future compatibility rather than needing nightly features.

https://lib.rs/stats#rustc-usage

For application development nightly hasn't been necessary for many years now. Places where people use nightly are increasingly just nice to haves and small optimizations.

Post reply on HN