[flagged]
i didnt know that it had been introduced in colleges when did that happen? i thought it would take a long time for colleges to include rust as it has a high learning curve
I dont know either, thats what I'm trying to figure out.
Rust in the Linux kernel: part 2
41–50 of 73 posts
Re: Rust in the Linux kernel: part 2
#42Earlier quoted context omitted.
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.
You can hammer an applications programming language to do systems things, but it will never be a good experience nor have optimal performance.
Re: Rust in the Linux kernel: part 2
#43[flagged]
> Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again This is not how learning programming languages works
You are correct, but its still a fair bit of effort and muscle memory that needs to be developed, I'm trying to figure out if the payoff is worth it.
Re: Rust in the Linux kernel: part 2
#44The rust driver does read better. I like that the functions are organized as methods under a member less struct, as opposed to the C version where they are top level with_really_long_function_names that take a struct parameter.
Re: Rust in the Linux kernel: part 2
#45Re: Rust in the Linux kernel: part 2
#46Earlier quoted context omitted.
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.
Could you write interrupt handlers in it? You can't even do synchronous signal handling in Java.
Re: Rust in the Linux kernel: part 2
#47Earlier 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]
> mainstream compilers provide support to detect and throw warnings/errors for some of these issues
You cannot detect all of these issues with static analysis. Rust does it by requiring the programmer to annotate lifetime dependencies in the source code. Without this additional semantic information, static analysis cannot fully reason about the lifetimes of variables.
There are efforts by some to introduce lifetime annotations to C++ (https://news.ycombinator.com/item?id=30888172), but any changes to the core language face a very steep uphill battle with the C++ standards committee, so any movement on this is likely to be compiler-specific attribute-based systems, adopted largely by companies invested in a particular compiler ecosystem (such as Apple or Google) to annotate their proprietary code.
On top of this, Rust is a very expressive language, with its features (like enum sum-types, traits etc) making it very easy to implement patterns such as compiler-checked state machines and polymorphism that doesn't involve the recognized downsides of class hierarchies.
It is not for everyone, and not for every kind of project, but its features resonate positively with a lot of people in systems programming because of their experiences with other systems languages and their downsides.
This is why Rust is popular today, particularly in certain communities.
Re: Rust in the Linux kernel: part 2
#48Earlier quoted context omitted.
Presumably because decades of experience has shown that it doesn't. Also insofar as avoiding certain pervasive security issues it can't.
> Presumably because decades of experience has shown that it doesn't. What definition of "doesn't" do you adhere to? Because there are use-after-free CVEs from Rust code. https://nvd.nist.gov/vuln/detail/CVE-2025-48752
This is not a very good example, because this Rust code is a thin wrapper around pthread_mutex, which is an unsafe API that can cause undefined behavior (such as use after free) if used incorrectly. The Rust code in question is using the unsafe C API incorrectly.
https://github.com/Forestryks/process-sync-rs/issues/3
One could say "Rust doesn't stop you from calling out into unsafe C code, so it's still possible to produce memory vulnerabilities in Rust", and it would be true, but it kind of misses the point and only really bolsters the Rust people when they say they want to rewrite everything in Rust.
In Rust, an API with a rule such as "you must check that the mutex is unlocked before you can destroy it" would be implemented using the type system in such a way as to make it impossible to drop it without checking its state. This is something that is not possible to do in C and cumbersome to do in C++.
Re: Rust in the Linux kernel: part 2
#49Earlier quoted context omitted.
[flagged]
> mainstream compilers provide support to detect and throw warnings/errors for some of these issues You cannot detect all of these issues with static analysis. Rust does it by requiring the programmer to annotate lifetime dependencies in the source code. Without this additional semantic information, static analysis cannot fully reason about the lifetimes of variables. There are efforts by some to introduce lifetime a…
[flagged]
Re: Rust in the Linux kernel: part 2
#50Earlier quoted context omitted.
i didnt know that it had been introduced in colleges when did that happen? i thought it would take a long time for colleges to include rust as it has a high learning curve
I dont know either, thats what I'm trying to figure out.
I do not even have CS degree or programming background. But Rust seemed easier to learn than C or C++. Well I've learned C syntax in a day but really using it is different story. Rust gave me confidence to contribute to existing (open-source) project pretty early.