Live data from Hacker News

Rust in the Linux kernel: part 2

lwn.net

11–20 of 73 posts

Re: Rust in the Linux kernel: part 2

#11

[flagged]

I mean I don't mind learning it if it solves problems and is reasonably enjoyable to program in (which I find C/C++ to be) but the rebel in me doesn't want to conform to what big business/politics wants I guess. I know thats a terrible metric to use in this field.

How does the rebel square itself with the fact of using big business/politics mandated C++?

Re: Rust in the Linux kernel: part 2

#12

[flagged]

I mean I don't mind learning it if it solves problems and is reasonably enjoyable to program in (which I find C/C++ to be) but the rebel in me doesn't want to conform to what big business/politics wants I guess. I know thats a terrible metric to use in this field.

I think it's the rust folk who are the rebels. Status quo types would never advocate for something so tumultuous as a new systems programming language.

Re: Rust in the Linux kernel: part 2

#13
post #9

Earlier quoted context omitted.

The general spike in interest from 2021 onwards (the language has been around for a while so it's not like people just found out) is due to a large hangover from crypto folks who become jobless after the bust. Super savvy in general being online and evangelism. The safety stuff is overblown (small subset of applications primarily OS and browsers) and full rewrite is not possible or advisable.

This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.

In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code).

In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program.

Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm.

Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.

Re: Rust in the Linux kernel: part 2

#14
post #9

Earlier quoted context omitted.

The general spike in interest from 2021 onwards (the language has been around for a while so it's not like people just found out) is due to a large hangover from crypto folks who become jobless after the bust. Super savvy in general being online and evangelism. The safety stuff is overblown (small subset of applications primarily OS and browsers) and full rewrite is not possible or advisable.

This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.

Presumably because decades of experience has shown that it doesn't. Also insofar as avoiding certain pervasive security issues it can't.

Re: Rust in the Linux kernel: part 2

#15
post #13

Earlier quoted context omitted.

This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.

In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside t…

> In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code).

Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages.

Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.

Re: Rust in the Linux kernel: part 2

#18

Earlier quoted context omitted.

This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.

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

Re: Rust in the Linux kernel: part 2

#19
post #9

[flagged]

The general spike in interest from 2021 onwards (the language has been around for a while so it's not like people just found out) is due to a large hangover from crypto folks who become jobless after the bust. Super savvy in general being online and evangelism. The safety stuff is overblown (small subset of applications primarily OS and browsers) and full rewrite is not possible or advisable.

[dead]

Re: Rust in the Linux kernel: part 2

#20

[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 have it mesh well with the language rather than having some weird workarounds.

For many people, the most interesting aspect of Rust is that it builds into its type system a set of rules that makes it much more practical to avoid memory safety issues or concurrency issues--lifetimes and Send/Sync are an absolute godsend for such programming, especially because it means you get the compiler to kick you in the face when you screw it up. Rather famously, Mozilla attempted a couple of parallel layout engines in C++ but their attempts all failed, because it just wasn't feasible to shake out all of the concurrency issues; their first attempt at doing so in Rust had none of those issues. It's not that the rules are complicated or hard to follow, it's that in large codebases, the invariants you need to uphold are described only in comments and can be easy to forget.

Post reply on HN