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

351–360 of 853 posts

Re: Rust in the kernel is no longer experimental

#351

Post by nialv7 »

johncolanduoni wrote: post #244
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)

What if I told you… there was a simple, constant environment variable you could set to make the stable compiler forget it isn’t a nightly?

the point is unstable features aren't guaranteed to not break after a compiler update. hence the specific version thing.

Re: Rust in the kernel is no longer experimental

#352

Post by pjmlp »

gjajric2 wrote: post #330
pjmlp wrote: post #270

Earlier quoted context omitted.

What matters is what Apple thinks, and officially it is, to the point it is explicitly written on the documentation.

The practical reality is arguably more important than beliefs. Apple has, as it turns out, invested in trying to make Swift more suitable for kernel and similar development, like trying to automate away reference counting when possible, and also offering Embedded Swift[0], an experimental subset of Swift with significant restrictions on what is allowed in the language. Maybe Embedded Swift will be great in the future…

You show a lack of awareness that ISO C and C++ are also not applicable, because on those domains the full ISO language standard isn't available, which is why freestanding is a thing.

Re: Rust in the kernel is no longer experimental

#354

Post by pjmlp »

vlovich123 wrote: post #326
pjmlp wrote: post #253

Earlier quoted context omitted.

Commercial embedded OSes, game consoles, for example.

Seems like game consoles for example has been accomplished by at least one dedicated team even if the vendor nor upstream provide official support: https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky... I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and ther…

Being supported on a games console means that you can produce binaries that are able to go through the whole approval process, and there is day 1 support for anything that is provided by the console vendor.

Otherwise is yak shaving instead of working on the actual game code.

Some people like to do that, that is how new languages like Rust get adoption, however they are usually not the majority, hence why mainstream adoption without backing from killer projects or companies support is so hard, and very few make it.

Also you will seldom see anyone throw away the confort of Unreal, Unity or even Godot tooling, to use Rust instead, unless they are more focused on proving the point the game can be made in Rust, than the actual game design experience.

Re: Rust in the kernel is no longer experimental

#355

Post by gf000 »

jcranmer wrote: post #20
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?

C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…

> that C can express that Rust cannot

The reverse is probably more true, though. Rust has native SIMD support for example, while in standard C there is no way to express that.

'C is not a low-level language' is a great blog post about the topic.

Re: Rust in the kernel is no longer experimental

#356

Post by gred »

shevy-java wrote: post #345

So what is written in Rust so far therein?

> Linux's DRM Panic "Screen of Death"

> "There is no particular reason to do it in rust, I just wanted to learn rust, and see if it can work in the kernel."

https://www.phoronix.com/news/Linux-DRM-Panic-QR-Codes

Re: Rust in the kernel is no longer experimental

#357

Post by sunshowers »

obviouslynotme wrote: post #71
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?

A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript. There will be small niches leftover: * Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers. * OS / Kernel - Nearly…

JavaScript does not have a separation between & and &mut.

Re: Rust in the kernel is no longer experimental

#359

Post by pjmlp »

bmacho wrote: post #325
pjmlp wrote: post #240

Earlier quoted context omitted.

I am yet to find one without it, unless you include Windows, consoles, or table/phone OSes, embedded RTOS, which aren't anyway proper UNIX derivatives.

According to the internet (can't check now) Alpine doesn't come with perl installed.

So a distribution mostly used to deploy containers.

Re: Rust in the kernel is no longer experimental

#360

Post by kristianp »

gf000 wrote: post #355
jcranmer wrote: post #20

Earlier quoted context omitted.

C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…

> that C can express that Rust cannot The reverse is probably more true, though. Rust has native SIMD support for example, while in standard C there is no way to express that. 'C is not a low-level language' is a great blog post about the topic.

So use the fairly common SIMD extensions in C, that's not much of an argument.
Post reply on HN