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

151–160 of 853 posts

Re: Rust in the kernel is no longer experimental

#151

Post by avhception »

vbezhenar wrote: post #92
scuff3d wrote: post #74

Earlier quoted context omitted.

I'm not on the Rust bandwagon, but statements like this make absolutely no sense. A lot of software was written in C and C++ because they were the only option for decades. If you couldn't afford garbage collection and needed direct control of the hardware there wasn't much of a choice. Had their been "safer" alternatives, it's possible those would have been used instead. It's only been in the last few years we've see…

One could rewrite curl with Perl 30 years ago. Or with Java, Golang, Python, you name it. Yet it stays written with C even today.

Your comment comes across disingenuous to me. Writing it in, for example, Java would have limited it to situations where you have the JVM available, which is a minuscule subset of the situations that curl is used in today, especially if we're not talking "curl, the CLI tool" but libcurl. I have a feeling you know that already and mostly want to troll people. And Golang is only 16 years old according to Wikipedia, by the way.

Re: Rust in the kernel is no longer experimental

#152

Post by LtWorf »

littlestymaar wrote: post #91
greesil wrote: post #84

Earlier quoted context omitted.

Shitloads of already existing libraries. For example I'm not going to start using it for Arduino-y things until all the peripherals I want have drivers written in Rust.

Why? You can interact with C libraries from Rust just fine.

But you now have more complexity and no extra safety.

Re: Rust in the kernel is no longer experimental

#153

Post by IshKebab »

keyle wrote: post #110
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 is fun to write. I can write Rust, but I prefer writing C. I prefer compiling C, I prefer debugging C. I prefer C. It's a bit like asking with the new mustang on the market, with airbags and traction control, why would you ever want to drive a classic mustang?

> I prefer debugging C

I prefer not having to debug... I think most people would agree with that.

Re: Rust in the kernel is no longer experimental

#154

Post by goku12 »

Aurornis wrote: post #96
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. Memory safety applies to all memory. Not just heap allocated memory. This is a strange claim because it's so obviously false. Was this comment supposed to be satire and I just missed it? Anyway, Rust has benefits beyond memory safety. > Rust is also too complex for smaller systems to write compilers. Rust uses LLVM as the compiler backend. There are already a lot of embe…

> Memory safety applies to all memory. Not just heap allocated memory.

> Anyway, Rust has benefits beyond memory safety.

I want to elaborate on this a little bit. Rust uses some basic patterns to ensure memory safety. They are 1. RAII, 2. the move semantics, and 3. the borrow validation semantics.

This combination however, is useful for compile-time-verified management of any 'resource', not just heap memory. Think of 'resources' as something unique and useful, that you acquire when you need it and release/free it when you're done.

For regular applications, it can be heap memory allocations, file handles, sockets, resource locks, remote session objects, TCP connections, etc. For OS and embedded systems, that could be a device buffer, bus ownership, config objects, etc.

> > Nearly all of the relevant code is unsafe. There aren't many real benefits.

Yes. This part is a bit weird. The fundamental idea of 'unsafe' is to limit the scope of unsafe operations to as few lines as possible (The same concept can be expressed in different ways. So don't get offended if it doesn't match what you've heard earlier exactly.) Parts that go inside these unsafe blocks are surprisingly small in practice. An entire kernel isn't all unsafe by any measure.

Re: Rust in the kernel is no longer experimental

#155

Post by hgs3 »

Rust in the kernel feels like a red herring. For fault tolerance and security, wouldn’t it be a superior solution to migrate Linux to a microkernel architecture? That way, drivers and various other components could be isolated in sandboxes.

Re: Rust in the kernel is no longer experimental

#157

Post by throw_a_grenade »

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…

Also you can't do self-referential strutcs.

Double-linked lists are also pain to implement, and they're are heavily used in kernel.

Re: Rust in the kernel is no longer experimental

#158

Post by debugnik »

sho_hn wrote: post #58
mmooss wrote: post #53

Earlier quoted context omitted.

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…

I still think you're off the mark. Again, most existing Rust developers are not "blank slate Rust developers". That they do not rush out to rewrite all of their past projects in C++ may be more about sunk costs, and wanting to solve new problems with from-scratch development.

> most existing Rust developers are not "blank slate Rust developers"

Not most, but the pool of software devs has been doubling every five years, and Rust matches C# on "Learning to Code" voters at Stack Overflow's last survey, which is crazy considering how many people learn C# just to use Unity. I think you underestimate how many developers are Rust blank slates.

Anecdotically, I've recently come across comments from people who've taught themselves Rust but not C or C++.

Re: Rust in the kernel is no longer experimental

#159

Post by tgma »

hgs3 wrote: post #155

Rust in the kernel feels like a red herring. For fault tolerance and security, wouldn’t it be a superior solution to migrate Linux to a microkernel architecture? That way, drivers and various other components could be isolated in sandboxes.

Just use MINIX, or GNU Hurd.

Re: Rust in the kernel is no longer experimental

#160

Post by AceJohnny2 »

drnick1 wrote: post #14
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?

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.

> My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

if only due to the Lindy Effect

https://en.wikipedia.org/wiki/Lindy_effect

Post reply on HN