Linux royalty backs adoption of Rust for kernel code
-
What's in your mind does not coincide with the professional experience of Greg KH. You shoyld read what he had to say on the subject.
-
You're wrong, but it's possible the article gave you that impression. Read the mailing-list thread.
It's particularly worth reading Ted T'so's contribution, which (considering his rude behaviour at the recent con led to a previous round of this nonsense) seems much more positive.
-
Did somebody say "provably correct"?
Haskell has entered the chat
-
it would require kernel developers to be savvy in both C and Rust
From my experience knowing how both C and rust works makes you a better developer in both languages.
-
-
Because people already know C/C++.
-
Oh absolutely, but you could argue the same for learning lisp or mastering any functional programming language (list comprehensions, etc). It will improve your design patterns when you go back to an object oriented language with some elements of functional programming.
-
What?!? Actually, read the article? What is this, Reddit? /s
Seriously, though - let me spin the question around: what, in your mind, overlaps with what Greg said?
(plus, OP was just interested in people opinions - not whether they align/contradict with Greg, Linus, etc)
-
To add something to this: linux has avoided internal SPIs for a long time. It's often lauded as one of the reasons it hasn't ossified.
However, some subsystems have a huge amount of complexity and hidden constraint in how you correctly use them. Some of that may be inherent, but more of it will be accidental.
Wrapping type-erased shims around this that attempt to capture (some of) those semantics shines a light onto the problem. The effort raises good technical questions around whether the C layer can be improved. Where maintainers have approached that with an open mind, the results are positive for both C and Rust consumers. Difficult interfaces are a source of bugs; it's always worth asking whether that difficulty is inherent or accidental.
-
Whilst it's gotten a lot better in the -17 and -20 iterations, the fact that there was recently a doorstop book published solely on the subject of C++ initialisation semantics is pretty telling.
I really like what Herb Sutter's doing around cppfront; I still wouldn't use C++ unless I absolutely had to.
-
T [email protected] shared this topic
-
- There was a serious lack of current kernel developers (which I don't think there is)
Maybe not at the moment, but my understanding is that the pool of qualified C programmers is shrinking rapidly, because the old guard is all ageing out and there simply are not enough intermediate developers coding in C at the level that Kernel development requires.
Having a larger (and growing) pool of upcoming developers interested in systems programming and software excellence is one of the explicit stated reasons that Linus et al. considered Rust in the first place.
-
Okay? I know a half dozen languages well, and am pretty productive with a half dozen more. If you're an experienced software engineer, picking up a new language should be easy. If a language is useful for a given task, I use it. If another language offers benefits I want, I learn it.
It's like any other profession, why limit yourself to one tool? If a new tool comes out and does the job better, use it.
I love C and it's my first choice for low level work like microcontrollers. However, it's not great for larger projects, especially ones with significant security concerns, since subtle vulnerabilities in different areas could be combined to create an attack. Rust provides a lot of protection against common attacks without a performance cost, so it's a good choice.
-
Learning Rust made me a better C# programmer.
-
I think they know C a little better than just to be „productive” with it. And also a lot of those people are not so young anymore to learn a new language well enough to feel comfortable with writing a kernel in.
-
I’m still kind of on the fence about Rust in the kernel. Linux isn’t some random hobby project, there are serious people working for serious companies in the project. Rust has a clear value proposition w.r.t. it’s qualities as a language, but I don’t think it’s as clear on a system level.
Say I’m working for a large company as a dev, maintaining a subsystem (let’s say a driver). Letting other people (filthy casual hobbyists) mess around with their filthy type safety will eventually spill into my subsystem and cause extra work. I don’t want the extra work, I just want to have my driver working and then go home. And even if I’m okay with the extra work, my boss won’t be. Even the risk of extra costs down the line will be enough for some to shut it down completely.
There are boring people working for huge corporations with huge stakes in the Linux kernel. I don’t think they see that much value in Rust at the moment, and I think the Rust crowd might need to hire some MBAs if they want to expand their presence in the kernel.
-
Oh, so that’s actually a thing I specifically do not care about.
I tolerate MBA types at my job because they’re part of an equation that yields a paycheck to me. I don’t believe those MBA types should be in the discussion at this level at all.
In fact, that sort of insistence on implementation details from product and manager types who can’t ever fucking commit to addressing tech debt issues until the system is falling apart is one of the primary frustrations I have in my career.
-
Unsafe Rust may be similar to C, though even though there's wibbles like the borrow checker still running, you still get more guarantees about the code than with C. Safe Rust can, on occasion, look more like Haskell than C.
Are they both systems languages? Yes of course otherwise we wouldn't be talking about using them in the kernel. Makes no sense to extend the possible comparison candidates to include Prolog, arbitrarily making look C and Rust more similar by introducing a far-off comparison point.
-
Nah it's a different axis. Rust doesn't have a GC, you do need to think about memory, it's just that the compiler generally enforces things for you. You learn to think like borrowck thinks because you don't want to get yelled at. Going back to C then you suddenly mistrust a lot of code a lot more, and rightly so.
-
Rust lacks a language standard. Without that is meaningless programming something with pieces that may change in the future (like what happened with Python) is not a good idea in my opinion.