19 ms·
Next steps for Rust in the kernel
- oxplot 4y agoFor those with better understanding of where zig is at, why not zig for kernel development? Is it merely because it's still in heavy dev?
- mlindner 4y agoI think the answer to your question is also the answer to the question of how Zig achieves memory safety at compile time.
- Jensson 4y agoYeah, Rust is C with a sane version of C++'s RAI, Zig is C with a sane version of C++'s templates. Having Turing complete duck typed template metaprogramming is very fun and useful, but I understand why you wouldn't want that in huge security critical codebases.
- sondr3 4y ago> 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).
- TotoHorner 4y agoFor someone new to systems programming, should I just start with Rust? Or should I learn C/C++ first and then learn Rust? I've just done projects in Python,JS & Java so far.
- spoiler 4y agoI've personally been doing C and then C++ for about a decade before moving onto Rust 2-3 year ago. I don't think you're missing out on much by skipping C or C++, but I recommend dabbling in them a bit (doesn't matter if before/while/after learning Rust), as it will make you appreciate Rust more.
- oleganza 4y agoI learned Rust because I need to write low-level high-performance stuff and I don't want to spend time learning how to do it correctly in C++. Rust compiler automates many chores for me, just like any computer technology is supposed to.
- PerFartmann 4y agoKeep on using python and JS. When the time comes you can start with Rust
- Twisol 4y agoRust has a bit of a steeper learning curve at the start, but it pays off once you get used to it. C and C++ are deceptively simple at first, but as time goes on you keep discovering more nuances that affect most of your code. There's no real problem starting with Rust, especially if you have some experience with other languages. The biggest difference is going to be getting used to dealing explicitly with memory, since all the languages you listed have a garbage collector; but this is true of all of C, C++ and, Rust. Be kind to yourself -- don't expect it all to click instantly.
- sondr3 4y agoI started using Rust because I wanted a programming language that compiled to native binaries, and the choice at the time was really only C++, Go and Rust. In the end I chose Rust because it was new and shiny, and I've stuck with it. Never written a single unsafe line of code or anything low-level, it's just been CLI tools and web APIs.
- skywhopper 4y agoYou’ll ultimately need to know both. Lots of new stuff will be in Rust, but plenty of old C/C++ code won’t be going away in our lifetimes. I’d start with the one used by the projects you are most motivated to work on immediately.
- WiSaGaN 4y agoAny historical background for the reference of Perl by Torvalds?
- dijit 4y agoPerl is notorious for being "write only". As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects. I feel qualified to say such things as I've worked on a billion-line perl codebase before.
- bogeholm 4y ago_one billion lines of Perl_? Wow
- School-Cotton 4y agoI suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java. (I wouldn't be surprised if they still had sizable amounts of Perl in dark corners).
- nkozyra 4y agoThere's a spirograph guy in the corner, the only one left that knows perl, lurking out and trying to entice people with its merits. Long ago I worked primarily in perl and ... yeesh, I recognize maybe 30% of it when looking, and that's the directly-c-adjacent stuff. To be fair if I walked away from Rust for a year I'd probably be similarly lost.
- dhosek 4y agoI still will reach for Perl for the occasional quick one-of text-processing application, but I do spend a lot of time in perldoc when I do.
- Cthulhu_ 4y ago
- ElCheapo 4y agoLinus hates Perl? Heck, so my secret project of slowly replacing every Perl script in the kernel with C might even get approved...
- tialaramex 4y agoThe dislike of Perl in this context is that it's a write-only language. See Titus' recent talk about "Software Engineering languages" for some thoughts about that. https://www.youtube.com/watch?v=yA_wUiNuhSc https://www.youtube.com/watch?v=yA_wUiNuhSc C isn't a good software engineering language but it might be better than Perl. Or in this context, maybe not.
- deleted 4y ago[deleted]
- bitL 4y agoThat 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...
- camdenreslink 4y agoScala isn’t that complex unless you try to pretend it’s Haskell.
- crznp 4y agoTo me, Scala's issue is identity crisis, not complexity. Some of the community wanted to pretend it is Haskell, and others wanted a better version of Java. But if you want a JVM functional language, why not Clojure? If you want a better Java, why not Kotlin (or update Java). Scala is squeezed by more consistent alternatives on all sides. I don't think that Rust has the same issue: it has a clear (albeit potentially complex) vision of what it is trying to do, which is distinct from C and more consistent than C++.
- sideeffffect 4y agoI think "better Haskell on JVM" (in contrast to "worse Haskell") is a good identity for Scala to have. (Please note that this is an intentional hyperbole.) Of course, there are areas where Haskell is stronger than Scala (hint: modularity, crucial for good Software Engineering, is not one of them). And Scala has its own way of doing things, so just imitating Haskell won't work well. Examples of this "better Haskell" are https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/ and https://zio.dev/ https://zio.dev/ . All together, Scala may be a better choice for you if you want to do Pure Functional Programming. And is definitely less risky (runs on JVM, Java libraries interop, IntelliJ, easy debugging, etc...). None of the other languages you mentioned are viable in this sense (if also you want a powerful type system, which rules out Clojure). I agree that Rust's identity is pretty clear: a modern language for use cases where only C or C++ could have been used before.
- dblohm7 4y ago
- avgcorrection 4y agoMissing 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.
- up2isomorphism 4y agoLinus loses control over kernel for quite a long time already.
- bayindirh 4y agoI don't think he's trying to be an all-controlling BDFL. What I see is, he acts as a trim tab which steers the kernel to a general direction rather than a precise bearing.
- skywhopper 4y agoSounds 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.
- tl 4y agoRead 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++. [1]: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
- xedrac 4y agoRust 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.
- daptaq 4y agoI 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?
- dgs_sgd 4y agoWhat are the negative stereotypes you associate with Rust and Rust programmers?
- sidlls 4y agoThe belief that the problem of memory safety that Rust has some compile-time protections against is the only problem (or so much more important problem that the rest almost don’t matter) of programming, and that therefore Rust is the only sane choice to use for any project. There’s a reason that memes like “Rust Evangelism Strike Force” exist. That’s the biggest one, anyway. I picked up Rust for the first time 8 years ago. I liked it: it felt comfortable in my “worn” C++ hands. But the community outside of a very few core individuals who care deeply about the language’s success can be quite toxic and dismissive of anyone who suggests Rust isn’t basically perfect. And it was a bit of a turn off for me, personally.
- Klonoar 4y agoUh, what? I’ve found Rust as a project and community to be a very self criticizing group - they know when they’ve got it wrong. They’re simply right about one core thing and they’re loud about it when it comes up. Until something proves them wrong and steals their thunder… I don’t know what to tell you.
- Jensson 4y ago
- nequo 4y agoI always have reservations about clicking LWN "subscriber links" since I have not subscribed. Perhaps it's worth waiting a week before posting these? LWN's paywall is dropped at that point.
- pabs3 4y agoLWN folks are fine with subscriber links being posted here, they view it as a form of advertising and they get subscribers from it.
- nequo 4y agoThat is good to know. But I looked this up and what I've found is Jonathan Corbet saying in 2010 that "occasional" posting of subscriber links is fine.[1] I am not Jonathan Corbet so I don't know what he considers occasional. But this is the fourth LWN subscriber link posted in the past 7 days, and the eighth in the past 14 days.[2] For reference, LWN currently lists 10 paywalled posts, the oldest from 13 days ago.[3] Those posted on HN are nearly every paywalled article that they have. [1] https://news.ycombinator.com/item?id=1966033 https://news.ycombinator.com/item?id=1966033 [2] https://hn.algolia.com/?dateEnd=1663790400&dateRange=custom&dateStart=1662494400&page=0&prefix=false&query=lwn.net&sort=byDate&type=story https://hn.algolia.com/?dateEnd=1663790400&dateRange=custom&... [3] https://lwn.net/ https://lwn.net/
- pabs3 4y agoAgreed, the number of subscriber links is kind of high. If it still gets them extra subscribers, then probably its ok. I guess they are monitoring the numbers on that.
- rascul 4y agoYou might consider subscribing to get more of LWN's content as it's released. Some time ago, the wait for the paywall removal for information that was relevant to something I was doing then and possibly not a week later is what finally got me to subscribe.
- 4y ago
- abledon 4y agoI 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.
- Longlius 4y agoI'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.
- bestouff 4y agoGet good at Rust, the answer will come.
- vbtemp 4y agoTo the OP: This is the correct answer.
- pjkundert 4y agoI’m a C++ guy from back in the 90’s CFront days. I love Rust; I’d do any new project in Rust instead of C++. It’s worth the effort to learn.
- agumonkey 4y agoHow did it affect your coding ? do you use different patterns / idioms ? are you more ambitious due to less bugs ? do you design / prototype differently ?
- ardel95 4y agoRust is significantly better than C++. And I say that as somebody who has done many years of C++ development.
- lijogdfljk 4y agoI love that it draws so many different types. I'm a Python/JS/Go programmer historically. Rust is closer to Go to me. Of course it's not Go, but i'm far from a migrating C/C++ dev. Hell i only know a pinch of C++ from when i was first learning the trade.
- keehun 4y agoDoes 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 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?
- surrTurr 4y agoIf 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.
- topbanana 4y agoI 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.
- dkryptr 4y agoI 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.
- atoav 4y agoA 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/9781492052586/ https://www.oreilly.com/library/view/programming-rust-2nd/97...
- javier_e06 4y agoRust 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.
- mlindner 4y agoI would say that that statement is a tautology of any new language and was true also of C and C++ when they were respectively introduced.
- _8j50 4y agoI 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.
- w10-1 4y agoI 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.
- Animats 4y agoWhatever happened to that effort to write a QNX-compatible kernel in Rust. The QNX kernel is tiny. That should be working by now. That's what you really want in Raspberry Pi sized projects.
- Kukumber 4y ago> 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
- klysm 4y agoYou’ve added nothing to the quote but vitriol.
- phendrenad2 4y agoI 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.
- menaerus 4y agoIf 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).