> Torvalds added that Rust isn't that terrible in the end; "it's not Perl".
Glowing endorsement from Torvalds right there. I'm really curious about how this will work out, Rust is my favourite programming language by a fair margin and seeing it being used more and more in places where C or C++ has traditionally dominated is very exciting. The future is looking bright (for those of us who like Rust).
That sounds like what we heard about Scala 10 years ago until complexity started to bite, and now that language is in a free fall and its parent company in financial distress...
Missing context? That came after a list of concerns and what-ifs about putting Rust in the kernel. Not an endorsement but also not a backhanded compliment, like you made it sound like with your cherry-picking.
I'm surprised Torvalds is so sanguine about Rust. Maybe it's age but I remember his epic gamer rant about how he would never allow C++ in the kernel. Either Rust is significantly better than C++ in his view, or he's accepted that C is likely not going to be the dominant systems programming language forever and opted for the least dangerous alternative.
Guess I should start my 5th attempt at finally getting good at Rust.
> Either Rust is significantly better than C++ in his view
Probably this one:
- Rust has the clear goal of memory safety, which is an active issue in the kernel (see: Kees Cook's Kernel Self Protection Project), even more so when it comes to drivers which are a lot more variable in quality and have very variable levels of oversight, which is why those are the primary use case.
- Rust has a much more expressive type system, especially without the need to go into template weeds.
- Rust has a lot less implicit behaviours.
- Rust features tend to be more orthogonal and mis-interact less with one another.
- While Rust has a fairly steep learning curve, short of unsafe it doesn't kneecap you, if it doesn't like what you're doing (right or wrong) it tells you, it doesn't go off into the weeds doing the wrong thing.
C++ is kind of like the Blub language. If you know C++ well enough, you can do anything you need to do, so something like Rust just seems too esoteric and weird and pretentious.
Fortunately, I spent many years using Rust recently (coming from primarily a C background) and when I'm on a project using C++, it just feels too weird and rudimentary and horribly over-complicated.
To end with a quote from the PG article:
_But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub._
I think it's both. I remember reading at one point (not sure if it was quote or speculation) that the difference is C++ adds a lot of abstractions that:
- Have hidden costs
- Have sneaky failure-modes
C just... doesn't add any abstractions. And then Rust adds abstractions, but makes a concerted effort to avoid ones that have these two problems
I always had the impression Linus saw C++ as C but more complicated/worse. Rust is DIFFERENT by creating guarantees that are harder to get around and if you do try by using the functionality available in unsafe blocks it is clear as day to anyone and everyone who looks at the code.
I think a lot of it comes from the fact that he realizes there is a demand for kernel maintainers in the future and the C expertise isn't there as well. If you can get maintainers to come in that are Rust devs then they can work on things without introducing significant issues due to some of the default safety guarantees and guardrails that Rust provides while at the same time having approximate to near performance parity
> Guess I should start my 5th attempt at finally getting good at Rust.
The thing that finally made Rust click for me was doing a usb HID project. Suddenly all the machinery around ownership and multi-threading made sense and I was able to get things done, and I could suddenly also do all the things I previously attempted to do in Rust.
>Guess I should start my 5th attempt at finally getting good at Rust.
I guess i should do the same too but I have really and man the language is not easy to grok. These days it also feels like if you don't know Rust, you are somewhat "old school".
Sounds like Torvalds is taking a measured and pragmatic approach. Which is the only thing that will work. Kudos for taking it slow, allowing maintainers to opt out until the integrations are more proven, and resisting the urge to rush such a huge change. If anything, Linus is moving very rapidly, given that Rust still requires unstable features to work with the kernel.
I have a number of negative stereotypes associated with Rust and Rust programmers that I am trying to set aside right now and just look at this from a technical perspective. Has the Rust-portability situation been addressed? Or will this change restrict the number of platforms the Linux kernel will be usable on? Assuming that is the case (I remember reading that GCC will acquire Rust support), what will the advantages be? I would guess stability might improve due to more static analysis, but what about performance? Build-time? And will this have any effect on Rust?
Rust in the kernel is starting with drivers, so if there's a Rust driver for something, it's presumably for hardware that's on a supported platform. Regardless, if you only want C-written work, you're no worse off.
The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc.
As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development.
The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases.
The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.
I was very put off from Rust because of the people acting out those stereotypes that I've encountered whenever the topic comes up. But then I decided to just learn it (partially driven by work requirements), and it's honestly great. I don't think we should be rewriting a ton of software just because there's better compiler-level safeguards, but it does make it much harder to shoot yourself in the foot without realizing it. There's some issues, dynamic linking isn't really supported. I've had good luck with various embedded targets, having trialed STM32F4s, RP2040, ESP32-C3, and am waiting on getting an NRF52840. Surprisingly, the ESP32-C3 is the best out of the box experience I've had, but library support is just not there.
IMO Rust is a really good language, and it deserves it's place in the toolbelt of most systems programmers. It's not always the right choice, but it's usually a good choice.
Read the article, mentally replacing Rust with C++ (or terms like gccrs with g++). Interesting times for the kernel; you have to wonder whether Rust will be a success or if there will be a repeat of the 1992 attempt [1] to include C++.
Rust brings a lot more to the table than C++ does - it solves many of the "hard" problems, at compile time, that kernel developers have to constantly grok with. I have a feeling, that it'll not only do well in the Kernel, but may eventually become the preferred language.
Does anyone have good resources to learning rust? I have a fairly good working knowledge of C, C++, and Swift.
I understand there's the Rust Book, Rustlings, and Rust By Example at https://www.rust-lang.org/learn. Are there other good resources? Does anyone have a strong suggestion on which of those official resources I should start with?
Start with the Rust book. Then "Rust for Rustaceans" by John Gjengset is a fantastic resource to learn about more than just the basics. He posts hour long videos on his youtube where he explains the concepts that he mentions in his book. I found that reading a chapter and then watching one of his videos really taught me about /why/ the language is as it is, rather than just learning to get the compiler to be happy. (It also includes chapters about API design and what to look out for if you are going to publish your own crate)
Rust has enough rare or novel concepts that trying to learn on the job with no book learning whatsoever is really reserved for the rarefied few. Though I understand that a lot of C and C++ concepts port quite easily, it also differs from those languages (especially C++ for advanced features) that doing a bit of a reset will avoid future pains e.g. Rust's concepts of copy, move, references, ... are very different from C++'s and going in half-cocked will be frustrating.
If you‘re willing to spend money on a great book that teaches you all the basics of Rust, I can only recommend Programming Rust, 2nd edition (OReilly). It includes tons of examples, code snippets and is also a good resource for looking up stuff once you‘re done reading it. It also includes many passages comparing C++ with Rust, so that might be useful for you.
It‘s a great book for anyone, who already knows a few programming languages. Programming beginners, should look elswhere tho.
A few things. The hardest thing about Rust is to forget many of tthe paradigms or aesthetical ideas other languages hammered into your brain. Programming Rust like you would program Python, Javascript or C++ is going to give you a hard time, but each time in a different way. If you program Rust in the Rust way, suddenly things become easy.
That means what the best way to start is depends on your background. In my eyes you can do nothing wrong with going through the rust book you already mentioned. Having read 4 different Rust books I have to say this introduction in combination with "Programming Rust" by Jim Blandy, Jason Orendorff, Leonora F. S. Tindall is probably the best way to get started. https://www.oreilly.com/library/view/programming-rust-2nd/97...
So, with "good working knowledge" of C++ and Swift, you probably aren't going to have too much trouble with the basics, if anything you might worry that there's some subtlety which you're missing when actually nope, whatever just seemed easy maybe actually was that easy.
[ For example move really is as simple as Rust makes it look, it is a headache in C++ because they added it to a finished working language ]
Several people suggested books/ web pages let me suggest some videos:
Jon Gjengset's "Crust of Rust" Youtube videos are good once you reach the point where you can write more than "Hello, world!" with some confidence but certain specific things aren't clicking.
For example, Jon does a whole video on lifetime annotations, which are something you won't see in most popular languages, but also one on Rust's iterators, which are a familiar concept from both C++ and Swift but don't work quite like either (they're very different from C++ iterators, your Swift experience will help more).
I recommend watching specifically a handful on topics you don't feel you understood well, although you could watch all of them especially if you just enjoy Jon's style and have the free time. They're not fast paced, if you wanted "Rust in 60 minutes" this is not that, but each one is actually writing carefully chosen code that runs and talking through what's going on, not just clicking through slides.
I think there's a missing book - 'Thinking In Rust'. The mechanics of borrow-checking, lifetimes, std lib, tokio can all be learned quite quickly. It's the muscle memory of techniques and design patterns that takes the longest to re-learn.
Just go through everything in "3 Syntax and Semantics" and "4 Effective Rust", you already know how to program C and C++ so that is all you should need to know. Took me a few days.
(2) Do "exercises" (small side projects, advent-of-code, rustlings. ..etc),
(3) Go through "Rust for Rustaceans". It's specifically targetted at "intermediate Rust developers". If you have "good working knowledge" of C and C++, I will wager that you will absolutely love this book, because, to me, (1) it explained so much of Rust's design choices, and (2) you will learn so much so quickly.
I learned it combining the Book and Rustlings. There's a table in the exercises directory mapping the exercises to the chapters of the book, so I'd every day do the exercises for yesterdays chapter first before todays chapter to have some sort of spaced repetition. For more material, check out https://github.com/jondot/rust-how-do-i-start
I started with the book to learn the fundamentals. I didn't get very far before I decided to rewrite an existing API I had in Python into Rust.
It definitely took some time and learning but now I have 6 Rust API microservices, a few scheduled/queue-reading services, and a shared library for common models/utils/providers.
I appreciate the write-up representing the flow of discussion, not just the outcome, for the insight it carries about how decisions move through the group.
It appears Linus has said it is happening, and a bit how it should happen, but has not given strong guidance or even parameters on how long any experiment would last.
Instead, he says the maintainers can decide to accept or reject or use Rust however they like. He doesn't even say they should state their policy, so they can let people try and still reject them.
Giving maintainers the ultimate discretion I think tracks the incentive system in the kernel: maintainers, who do boatloads of work, get to be deciders. That also gives companies a strong incentive to employ maintainers.
On the tools front, Linus expressly said he wants not just an anointed compiler on kernel.org, but compilers from the distributors. He's driving Rust normalization and platform adoption as a condition of use, even though the kernel historically adopts a fairly narrow (if not archaic) set of tools.
Somehow this all seems like a bunch of rafts tied together with (platform) boats pushing at the edges -- somewhat tenuous, hard to drive, but vaguely heading in the right direction.
As others have mentioned, it's interesting that Linus and many maintainers are getting older, and instead of getting freedom and flexibility in their maturity, they can look forward to more low-level bouts of increasing complexity. When they talk about the integration of Rust, they're clearly anticipating it might not fully happen until after they're gone. That, too, could change the incentives.
I believe that in 10 years, we'll look back at Rust in the kernel and see it as a big disaster. Some people will blame the kernel team (they didn't adopt Rust well enough), and some will blame Rust itself (writing a non-toy kernel in it hasn't been tried before).
But heck, we should TRY it. So I'm glad this is finally happening.
Rust covers an infinitesimal footprint of the C/C++ code out there running the world. Rust won't replace anything substantial or meaningful in the embedded world for the time being.
If this happens, and it seems inevitable at the moment, I personally see this resulting in a potential decline of a Linux kernel in the next few years.
Just a few questions off top of my head:
* How much will it affect the development velocity? Existing devs (and maintainers) will at least need to learn how to read and debug Rust code. New devs will likely have no good competences in C which is 99% of the codebase so how good/quickly will they be able to blend in?
* How many existing kernel developers will community potentially loose because of the increased complexity?
* How much new talent will it actually be able to attract? Now people will need to learn two completely different languages and their vastly different ecosystems.
* Does Rust have high enough entry bar to produce competent kernel developers? Sometimes high entry bar acts as a very good filter to end up in a pool with a highly skilled (and motivated) engineers.
* Coordination of development efforts is now going to become much more complex. This includes writing new features (C or Rust or both?), maintaining the old ones (rewrite pieces in Rust or not?) but also code-reviews which will now pose a bigger challenge given that it will consist of mixed Rust+C code.
Having worked in codebases which mixed C and C++, I already understand what kind of issues mixing C and Rust is going to produce. And I expect them to be much more accentuated because distance(C, C++) << distance(C, Rust).
I love this, but also very surprised Trovalds is ok with a language that changes so much. But with git and all it maybe easier to manage just as if you would C89/99/11.
I know the article is serious, but it has the writing-style of an onion/babylonbee article lol.
esp the last paragraph:
>As time ran out, Matthew Wilcox asked whether kernel developers should be writing idiomatic Rust code, or whether they will be writing "C in Rust". Ojeda answered that code might be more C-like toward the beginning; adoption of more advanced features (such as async) might take longer. Gleixner asked what could be done to prevent developers from using unstable features (once the features used by the kernel are stabilized); the answer was to specify the version of the compiler to be used with kernel development.
> Instead, Bottomley suggested that, rather than bringing in Rust, it might be better to just move more Rust-like features into C. Ojeda said that he has actually been working with the C language committee to push for that to happen, but any such change will take a long time if it happens at all. Christoph Hellwig said that this sort of change will have to happen anyway unless the plan is to rewrite the whole kernel in Rust; he was not pleased at the idea of rewriting working code in a new language. Perhaps the sparse static analyzer could be enhanced to do more Rust-like checking, he said. Ojeda answered that the result of such efforts would be like having Rust — but much later.
Some reasonable people in this sea of sectarian crabs, glad to hear that
[+] [-] sondr3|3 years ago|reply
Glowing endorsement from Torvalds right there. I'm really curious about how this will work out, Rust is my favourite programming language by a fair margin and seeing it being used more and more in places where C or C++ has traditionally dominated is very exciting. The future is looking bright (for those of us who like Rust).
[+] [-] ElCheapo|3 years ago|reply
Heck, so my secret project of slowly replacing every Perl script in the kernel with C might even get approved...
[+] [-] bitL|3 years ago|reply
[+] [-] WiSaGaN|3 years ago|reply
[+] [-] TotoHorner|3 years ago|reply
Or should I learn C/C++ first and then learn Rust?
I've just done projects in Python,JS & Java so far.
[+] [-] up2isomorphism|3 years ago|reply
[+] [-] avgcorrection|3 years ago|reply
[+] [-] Longlius|3 years ago|reply
Guess I should start my 5th attempt at finally getting good at Rust.
[+] [-] masklinn|3 years ago|reply
Probably this one:
- Rust has the clear goal of memory safety, which is an active issue in the kernel (see: Kees Cook's Kernel Self Protection Project), even more so when it comes to drivers which are a lot more variable in quality and have very variable levels of oversight, which is why those are the primary use case.
- Rust has a much more expressive type system, especially without the need to go into template weeds.
- Rust has a lot less implicit behaviours.
- Rust features tend to be more orthogonal and mis-interact less with one another.
- While Rust has a fairly steep learning curve, short of unsafe it doesn't kneecap you, if it doesn't like what you're doing (right or wrong) it tells you, it doesn't go off into the weeds doing the wrong thing.
[+] [-] vbtemp|3 years ago|reply
Do you remember the Paul Graham essay on the Blub programming language? (http://www.paulgraham.com/avg.html)
C++ is kind of like the Blub language. If you know C++ well enough, you can do anything you need to do, so something like Rust just seems too esoteric and weird and pretentious.
Fortunately, I spent many years using Rust recently (coming from primarily a C background) and when I'm on a project using C++, it just feels too weird and rudimentary and horribly over-complicated.
To end with a quote from the PG article:
_But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub._
[+] [-] pjkundert|3 years ago|reply
I love Rust; I’d do any new project in Rust instead of C++.
It’s worth the effort to learn.
[+] [-] brundolf|3 years ago|reply
- Have hidden costs
- Have sneaky failure-modes
C just... doesn't add any abstractions. And then Rust adds abstractions, but makes a concerted effort to avoid ones that have these two problems
[+] [-] ardel95|3 years ago|reply
[+] [-] runevault|3 years ago|reply
[+] [-] endorphine|3 years ago|reply
Rust though? That could make the kernel more secure in the long-term and rule out a whole class of bugs. This makes sense.
[+] [-] nyxtom|3 years ago|reply
[+] [-] bestouff|3 years ago|reply
[+] [-] sam0x17|3 years ago|reply
The thing that finally made Rust click for me was doing a usb HID project. Suddenly all the machinery around ownership and multi-threading made sense and I was able to get things done, and I could suddenly also do all the things I previously attempted to do in Rust.
[+] [-] Tolexx|3 years ago|reply
I guess i should do the same too but I have really and man the language is not easy to grok. These days it also feels like if you don't know Rust, you are somewhat "old school".
[+] [-] jahewson|3 years ago|reply
You say that like there’s some scalar measure of “better”.
[+] [-] skywhopper|3 years ago|reply
[+] [-] daptaq|3 years ago|reply
[+] [-] schuyler2d|3 years ago|reply
The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc.
As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development.
The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases.
The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.
[+] [-] packetlost|3 years ago|reply
IMO Rust is a really good language, and it deserves it's place in the toolbelt of most systems programmers. It's not always the right choice, but it's usually a good choice.
[+] [-] tl|3 years ago|reply
[1]: http://harmful.cat-v.org/software/c++/linus
[+] [-] xedrac|3 years ago|reply
[+] [-] keehun|3 years ago|reply
I understand there's the Rust Book, Rustlings, and Rust By Example at https://www.rust-lang.org/learn. Are there other good resources? Does anyone have a strong suggestion on which of those official resources I should start with?
[+] [-] 8jy89hui|3 years ago|reply
[+] [-] masklinn|3 years ago|reply
The rust book. Reading it start to finish provides a very good basis.
And if you're tempted to "learn by doing" with the usual linked lists, go and read "learning rust with entirely too many linked lists": https://rust-unofficial.github.io/too-many-lists/
Rust has enough rare or novel concepts that trying to learn on the job with no book learning whatsoever is really reserved for the rarefied few. Though I understand that a lot of C and C++ concepts port quite easily, it also differs from those languages (especially C++ for advanced features) that doing a bit of a reset will avoid future pains e.g. Rust's concepts of copy, move, references, ... are very different from C++'s and going in half-cocked will be frustrating.
[+] [-] surrTurr|3 years ago|reply
[+] [-] atoav|3 years ago|reply
That means what the best way to start is depends on your background. In my eyes you can do nothing wrong with going through the rust book you already mentioned. Having read 4 different Rust books I have to say this introduction in combination with "Programming Rust" by Jim Blandy, Jason Orendorff, Leonora F. S. Tindall is probably the best way to get started. https://www.oreilly.com/library/view/programming-rust-2nd/97...
[+] [-] tialaramex|3 years ago|reply
[ For example move really is as simple as Rust makes it look, it is a headache in C++ because they added it to a finished working language ]
Several people suggested books/ web pages let me suggest some videos:
Jon Gjengset's "Crust of Rust" Youtube videos are good once you reach the point where you can write more than "Hello, world!" with some confidence but certain specific things aren't clicking.
https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVEr...
For example, Jon does a whole video on lifetime annotations, which are something you won't see in most popular languages, but also one on Rust's iterators, which are a familiar concept from both C++ and Swift but don't work quite like either (they're very different from C++ iterators, your Swift experience will help more).
I recommend watching specifically a handful on topics you don't feel you understood well, although you could watch all of them especially if you just enjoy Jon's style and have the free time. They're not fast paced, if you wanted "Rust in 60 minutes" this is not that, but each one is actually writing carefully chosen code that runs and talking through what's going on, not just clicking through slides.
[+] [-] topbanana|3 years ago|reply
[+] [-] Jensson|3 years ago|reply
Just go through everything in "3 Syntax and Semantics" and "4 Effective Rust", you already know how to program C and C++ so that is all you should need to know. Took me a few days.
[+] [-] davidatbu|3 years ago|reply
(1) Go through the Rust Book,
(2) Do "exercises" (small side projects, advent-of-code, rustlings. ..etc),
(3) Go through "Rust for Rustaceans". It's specifically targetted at "intermediate Rust developers". If you have "good working knowledge" of C and C++, I will wager that you will absolutely love this book, because, to me, (1) it explained so much of Rust's design choices, and (2) you will learn so much so quickly.
[+] [-] d12bb|3 years ago|reply
[+] [-] dkryptr|3 years ago|reply
It definitely took some time and learning but now I have 6 Rust API microservices, a few scheduled/queue-reading services, and a shared library for common models/utils/providers.
[+] [-] mfashby|3 years ago|reply
[+] [-] w10-1|3 years ago|reply
It appears Linus has said it is happening, and a bit how it should happen, but has not given strong guidance or even parameters on how long any experiment would last.
Instead, he says the maintainers can decide to accept or reject or use Rust however they like. He doesn't even say they should state their policy, so they can let people try and still reject them.
Giving maintainers the ultimate discretion I think tracks the incentive system in the kernel: maintainers, who do boatloads of work, get to be deciders. That also gives companies a strong incentive to employ maintainers.
On the tools front, Linus expressly said he wants not just an anointed compiler on kernel.org, but compilers from the distributors. He's driving Rust normalization and platform adoption as a condition of use, even though the kernel historically adopts a fairly narrow (if not archaic) set of tools.
Somehow this all seems like a bunch of rafts tied together with (platform) boats pushing at the edges -- somewhat tenuous, hard to drive, but vaguely heading in the right direction.
As others have mentioned, it's interesting that Linus and many maintainers are getting older, and instead of getting freedom and flexibility in their maturity, they can look forward to more low-level bouts of increasing complexity. When they talk about the integration of Rust, they're clearly anticipating it might not fully happen until after they're gone. That, too, could change the incentives.
[+] [-] phendrenad2|3 years ago|reply
But heck, we should TRY it. So I'm glad this is finally happening.
[+] [-] javier_e06|3 years ago|reply
[+] [-] mlindner|3 years ago|reply
[+] [-] menaerus|3 years ago|reply
Just a few questions off top of my head:
* How much will it affect the development velocity? Existing devs (and maintainers) will at least need to learn how to read and debug Rust code. New devs will likely have no good competences in C which is 99% of the codebase so how good/quickly will they be able to blend in?
* How many existing kernel developers will community potentially loose because of the increased complexity?
* How much new talent will it actually be able to attract? Now people will need to learn two completely different languages and their vastly different ecosystems.
* Does Rust have high enough entry bar to produce competent kernel developers? Sometimes high entry bar acts as a very good filter to end up in a pool with a highly skilled (and motivated) engineers.
* Coordination of development efforts is now going to become much more complex. This includes writing new features (C or Rust or both?), maintaining the old ones (rewrite pieces in Rust or not?) but also code-reviews which will now pose a bigger challenge given that it will consist of mixed Rust+C code.
Having worked in codebases which mixed C and C++, I already understand what kind of issues mixing C and Rust is going to produce. And I expect them to be much more accentuated because distance(C, C++) << distance(C, Rust).
[+] [-] Animats|3 years ago|reply
That's what you really want in Raspberry Pi sized projects.
[+] [-] oxplot|3 years ago|reply
[+] [-] mlindner|3 years ago|reply
[+] [-] badrabbit|3 years ago|reply
[+] [-] nequo|3 years ago|reply
Perhaps it's worth waiting a week before posting these? LWN's paywall is dropped at that point.
[+] [-] abledon|3 years ago|reply
esp the last paragraph: >As time ran out, Matthew Wilcox asked whether kernel developers should be writing idiomatic Rust code, or whether they will be writing "C in Rust". Ojeda answered that code might be more C-like toward the beginning; adoption of more advanced features (such as async) might take longer. Gleixner asked what could be done to prevent developers from using unstable features (once the features used by the kernel are stabilized); the answer was to specify the version of the compiler to be used with kernel development.
[+] [-] Kukumber|3 years ago|reply
Some reasonable people in this sea of sectarian crabs, glad to hear that