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

121–130 of 853 posts

Re: Rust in the kernel is no longer experimental

#121

Post by jandrewrogers »

lmm wrote: post #46
mmooss wrote: post #27

Earlier quoted context omitted.

Before we ask if almost all things old will be rewritten in Rust, we should ask if almost all things new are being written in Rust or other memory-safe languages? Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?

> Obviously not Is it obvious? I haven't heard of new projects in non-memory-safe languages lately, and I would think they would struggle to attract contributors.

New high-scale data infrastructure projects I am aware of mostly seem to be C++ (often C++20). A bit of Rust, which I’ve used, and Zig but most of the hardcore stuff is still done in C++ and will be for the foreseeable future.

It is easy to forget that the state-of-the-art implementations of a lot of systems software is not open source. They don’t struggle to attract contributors because of language choices, being on the bleeding edge of computer science is selling point enough.

Re: Rust in the kernel is no longer experimental

#122

Post by goku12 »

Archelaos wrote: post #48
joshdavham wrote: post #39

Earlier quoted context omitted.

I think on HN, people generally want the submission's title to match the page's title. (I do agree it's clickbait-y though)

I prefer improved titles. However, not in this case. It is rather irony, because LWN does not need click-bait.

This one is apparently a genuine mistake from the author. But I think we should leave it as it is. The confusion and the argument about it is interesting in itself.

Re: Rust in the kernel is no longer experimental

#123

Post by loeg »

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?

There are a number of oddball platforms LLVM doesn't support, yeah.

Re: Rust in the kernel is no longer experimental

#124

Post by lmm »

RealityVoid wrote: post #105
lmm wrote: post #51

Earlier quoted context omitted.

Newer web servers have already moved away from C/C++. Web browsers have been written in restricted subsets of C/C++ with significant additional tooling for decades at this point, and are already beginning to move to Rust.

> Web browsers have been written in restricted subsets of C/C++ with significant additional tooling for decades at this point So, written in C/C++? It seems to me you're trying to make a point that reality doesn't agree with but you stubbornly keep pushing it.

> So, written in C/C++?

Not in the sense that people who are advocating writing new code in C/C++ generally mean. If someone is advocating following the same development process as Chrome does, then that's a defensible position. But if someone is advocating developing in C/C++ without any feature restrictions or additional tooling and arguing "it's fine because Chrome uses C/C++", no, it isn't.

Re: Rust in the kernel is no longer experimental

#126

Post by qalmakka »

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…

> Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.

Modern embedded isn't your grandpa's embedded anymore. Modern embedded chips have multiple KiB of ram, some even above 1MiB and have been like that for almost a decade (look at ESP32 for instance). I once worked on embedded projects based on ESP32 that used full C++, with allocators, exceptions, ... using SPI RAM and worked great. There's a fantastic port of ESP-IDF on Rust that Espressif themselves is maintaining nowadays, too.

Re: Rust in the kernel is no longer experimental

#127

Post by jitl »

aw1621107 wrote: post #85
obviouslynotme wrote: post #71

Earlier quoted context omitted.

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…

> No memory allocation means no Rust benefits. This isn't really true; otherwise, there would be no reason for no_std to exist. Data race safety is independent of whether you allocate or not, lifetimes can be handy even for fixed-size arenas, you still get bounds checks, you still get other niceties like sum types/an expressive type system, etc. > OS / Kernel - Nearly all of the relevant code is unsafe. I think that…

The Temporal API in Chrome is implemented in Rust. We’re definitely seeing more Rust in browsers including beyond Firefox.

Re: Rust in the kernel is no longer experimental

#128

Post by Yiin »

thayne wrote: post #30
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.

> 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

Re: Rust in the kernel is no longer experimental

#129

Post by qalmakka »

jcranmer wrote: post #32
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.

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,…

We're already at the point where in order to have a "decent" desktop software experience you _need_ Rust too. For instance, Rust doesn't support some niche architectures because LLVM doesn't support them (those architectures are now exceedingly rare) and this means no Firefox for instance.

Re: Rust in the kernel is no longer experimental

#130

Post by vlovich123 »

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…

Can you expand on bitfields? There’s crates that implement bitfield structs via macros so while not being baked into the language I’m not sure what in practice Rust isn’t able to do on that front.
Post reply on HN