I'm curious, who's driving the interest in Rust. Do people learn it in CS degree's and thats all they know? Do orgs like it as a language because its considered safer in the sense that there are usually less bugs compared to C++ (and hence get it introduced into CS degrees)? Is it that C++ has become an abomination over time with added features? Cant we just use C++ as C with polymorphism and encapsulation? Is it generics that are the sticking point (and people don't like STL)? Or is it simply that a new gen just want to have their own thing to differentiate themselves from the oldies... its more cool.
I personally invested a lot of time and effort into learning C/C++ and the only new language with enough difference to come along that was worth learning was Python imho. Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again.
prydt · 1h ago
My interest in Rust comes from getting frustrated with C's type system. Rust has such a nice type system and I really enjoy the ownership semantics around concurrency. I think that C++ written "correctly" looks a lot like Rust and libkj [1] encourages this, but it is not enforced by the language.
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 years.
LeFantome · 1h ago
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.
globalnode · 1h ago
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.
__MatrixMan__ · 25m ago
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.
eviks · 42m ago
How does the rebel square itself with the fact of using big business/politics mandated C++?
npalli · 1h ago
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.
globalnode · 1h ago
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.
dafelst · 15m ago
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.
motorest · 1m ago
> 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.
michaelmrose · 11m ago
Presumably because decades of experience has shown that it doesn't. Also insofar as avoiding certain pervasive security issues it can't.
charcircuit · 4h ago
>The next article in this series will look at the design of the interface between the C and Rust code in the kernel, as well as the process of adding new bindings when necessary.
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
I personally invested a lot of time and effort into learning C/C++ and the only new language with enough difference to come along that was worth learning was Python imho. Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again.
[1] https://github.com/capnproto/capnproto/blob/v2/kjdoc/tour.md
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 years.
A language that makes it impossible to introduce 70% of the security bugs is appealing.
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.
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.
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
https://arxiv.org/abs/2506.03876
https://github.com/asterinas/asterinas
The reasons we encounter pattern issues forcing Linux into a polyglot is not a new phenomena:
https://en.wikipedia.org/wiki/Second-system_effect
Best regards =3