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

Rust in the Linux kernel: part 2

lwn.net

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Rust in the Linux kernel: part 2

#31

Post by joha4270 »

zx8080 wrote: post #26
LeFantome wrote: post #6

Earlier quoted context omitted.

Most of the interest I have seen is in pursuit of security. A few sources have cited that something like 70% of vulnerabilities are rooted in memory safety issues. A language that makes it impossible to introduce 70% of the security bugs is appealing.

Java does not have memory safety issues. But it's not appealing, apparently. So why Rust then?

Memory safe languages such as Java have already taken the world by storm, decades ago.

The interesting combination rust brings is a memory safe language that can compete with C and C++ for the speed crown.

Re: Rust in the Linux kernel: part 2

#32

Post by kaladin-jasnah »

izacus wrote: post #28
dafelst wrote: post #7

Earlier quoted context omitted.

Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++. That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25…

Cool, but so does Java. So why Rust advertising specifically?

One reason I can think of is its memory management model gives programmers more control than a garbage collector. With the borrow checker, you know when your variables will get dropped/deallocated, but a garbage collector is not necessarily as controllable.

Re: Rust in the Linux kernel: part 2

#33

Post by seangrogg »

globalnode wrote: post #4

[flagged]

As a person that occasionally daytrips into Rust and Zig, I'd imagine some number of us are coming from higher level languages (JS/TS, Python, etc) as our daily drivers and interested in what performance we could get closer to the metal.

In those cases we don't have a particular investment in C/C++, we don't know the differences between gcc or clang, we are used to package managers, don't manage header files, and things like comfy error messages and "if it compiles it's reasonably safe tm" are better than... Not having those things.

Meanwhile, outside of things like CUDA interop I don't know what the compelling case for C/C++ even is for someone who isn't invested.

Re: Rust in the Linux kernel: part 2

#34

Post by armada651 »

izacus wrote: post #28
dafelst wrote: post #7

Earlier quoted context omitted.

Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++. That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25…

Cool, but so does Java. So why Rust advertising specifically?

Because adopting a language that utilizes a garbage collector for memory management in the Linux kernel is even less likely than adopting Rust.

Re: Rust in the Linux kernel: part 2

#35

Post by thayne »

izacus wrote: post #28
dafelst wrote: post #7

Earlier quoted context omitted.

Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++. That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25…

Cool, but so does Java. So why Rust advertising specifically?

- Java's use of GC and a large runtime makes it inappropriate for many use cases

- Java had a pretty slow startup time, which makes it a poor fit for many CLI applications and similar

- Java has historically had pretty poor support for interoperating with c libraries (although this is improving with project panama)

- Rust has a richer, more powerful type system than Java (although scala's is more comparable)

- Rust's affine types (lifetimes) actually prevent certain types of bugs that occur in languages like Java as well. Things like using a connection or file handle after it is closed, forgetting to release a lock, not properly synchronizing access to memory between multiple threads, etc.

Re: Rust in the Linux kernel: part 2

#36

Post by dafelst »

motorest wrote: post #30
dafelst wrote: post #25

Earlier quoted context omitted.

> Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys. That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't. I have been writing C++ professionally since around 2000-2001, and have been working with Rust for about 18 months.…

[flagged]

It is entirely unclear to me what point you are trying to make. Is your mundane solution to just add more sanitization and analysis to C and C++? If so, that's great, more safety in any language is fantastic. My issue with that is that it is an optional addition to the language rather than the default behavior.

The point I am making is that safe Rust _by default_ straight up disallows compiling code that has the potential for the vast majority of memory safety issues. Code with those issues is just a plain invalid program, and will not compile. If you want to bypass those protections, you need to explicitly opt-in with the unsafe keyword.

C or C++ code with the same issues is perfectly valid, will compile and run, but it has the potential to be incorrect. You can (and should!) bolt on tools to fix that, but the issue is that the language allows that behavior by default. Until these tools are the defaults, the problem is only partially solved - you have to opt-in to a large chunk of safety features, and even if you do, you get fewer of them to boot.

I'm not saying you should use Rust by any means. If you like C++, continue using it. But the fact here is that Rust solves a bunch of problems here and now today that C and C++ cannot, so it is baffling to me that people have such a visceral negative reaction to it.

Re: Rust in the Linux kernel: part 2

#37

Post by globalnode »

jcranmer wrote: post #20
globalnode wrote: post #4

[flagged]

Rust is interesting because it's the first language to really try to compete in the same space as C and C++ in quite a long time. Part of being a newer language is that it doesn't have to work around the baggage of horribly bad past decisions (e.g., null-terminated strings, or implicit integer promotion). Part of it is also that it can adopt newer language features (e.g., structured binding or pattern matching) and h…

Thanks for that perspective.

Re: Rust in the Linux kernel: part 2

#38

Post by rjsw »

nullpoint420 wrote: post #29
zx8080 wrote: post #26

Earlier quoted context omitted.

Java does not have memory safety issues. But it's not appealing, apparently. So why Rust then?

Java is not a systems level programming language (at least in its modern OpenJDK form)

Sun tried out allowing Java in the kernel, it could be used to write device drivers just as Rust is being used now.

Re: Rust in the Linux kernel: part 2

#39

Post by nextaccountic »

izacus wrote: post #28
dafelst wrote: post #7

Earlier quoted context omitted.

Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++. That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25…

Cool, but so does Java. So why Rust advertising specifically?

Safe Rust is actually safer than Java because Java still has data races (that happen when you don't use correct synchronization when doing multithreaded code). In Java data races aren't as catastrophic as C (that is, it's not UB), but they are still a very severe kind of bug.

In Safe Rust, data races can't happen because you can only share stuff between threads if they are either synchronized or read only - attempting to share data that can't be accessed by many threads results in a compile time error.

Also: Java depends heavily on the GC to have memory safety. There are probably some kernels that manage memory with GCs, but for most of them it's not appropriate.

And even for projects that are written in a language that uses a GC (like written in Python, or Java, or C#), having two GCs in the same project, sharing data between each other, is kind of catastrophic. Because of this, a project in a high level language either uses libraries written in the same language (or at least the same runtime), or languages written in C or C++. So Python programs use Python libraries or C libraries, C# programs use C#/.NET libraries or C libraries. But it's uncommon to use a Python library in a C# project, or a C# library in a Python project.

Just like C, Rust fills the niche of writing libraries that can be used in many ecosystems. Right now some Rust libraries are used in Javascript projects (either on node or on the web, with wasm), for example.

Re: Rust in the Linux kernel: part 2

#40

Post by anextio »

izacus wrote: post #28
dafelst wrote: post #7

Earlier quoted context omitted.

Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++. That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25…

Cool, but so does Java. So why Rust advertising specifically?

Java does not provide performance comparable to C/C++.
Post reply on HN