24 ms·

Linus Torvalds: Rust for the Kernel Could Possibly Be Merged for Linux 5.20

392 points by FPGAhacker 4y ago

samuell 4y ago
Pardon my ignorance, but given the complexity of Rust, the incoherence of the async story etc, wouldn't something like Zig be a more reasonable choice for Linux, with its ability to be introduced gradually etc?
- usrn 4y ago
  I think zig is a little too opinionated.
  - vkazanov 4y ago
    It is, indeed, opinionated. It's also small and easy. Rust is superopinionated. Big and complex as well.
    - usrn 4y ago
      Yeah I'm not a fan of Rust either. It has some great ideas though. Part of me wants to try writing my own language after I finish my current side project.
      - jeroenhd 4y ago
        You may be interested in Jakt, an experimental language written for SerenityOS. It has some very Rust-like festures for memory safety but no borrow checker or async (at least, not at the moment). Currently, it compiles into C++ as it's written specifically for an entire operating system written in C++ but I can see native compilation becoming an option down the line. It's far from stable but it's worth looking at: https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt
    - 127 4y ago
      Writing multi-line strings in Zig is not easy.
      - kristoff_it 4y ago
        I really don't understand why people have issues with Zig's multiline syntax. \\I really don't \\understand why people \\have issues with \\Zig's multiline syntax
        lostmsu 4y ago
        I never used Zig, but used many other languages, and that looks better than most which don't have line prefix like \\: in languages that don't need it there is confusion about significance of whitespace in the beginning of 2nd+ lines.
        kristoff_it 4y ago
        Yep, that's precisely what that sintax solves, and also makes it easier to build a grammar for it (think of editor syntax highlighting for example) because the multiline marker is repeated in every line, instead of being a contextual marker. This is the same reason why Zig doesn't have dedicated multiline comment syntax.
        127 4y ago
        - Can't easily indent - Can't easily copy paste - Can't easily edit - Looks ugly - Harder to read
      - vkazanov 4y ago
        Huh? It might be slightly wordy, but otherwise very simple and easy for both people and computers to read. Even a primitive editor with primitive highlighting can make the syntax painless. Reasoning: https://github.com/ziglang/zig/issues/162 https://github.com/ziglang/zig/issues/162
    - oconnor663 4y ago
      Rust definitely has its opinions and its chosen complexities. I'd point to the way global allocators are used by default (opinionated) and the way trait coherence rules work (opinionated and kind of complicated). That said, I think a lot of the complexity of Rust is actually fallout from a relatively small number of design choices: - programs ought to be UB-free by default, and overriding those defaults should be rare - mutation is allowed, including shared mutation across threads - runtime assumptions similar to C and C++, i.e. no garbage collector, and a useful subset of the lanugage doesn't require heap allocation Given those requirements (in short, a "safe systems programming language"), I think you very quickly find yourself needing 1) lifetimes, 2) the no-mutable-aliasing rule, and 3) move semantics. Those things contribute a lot of the "feel" of Rust, and probably the majority of the difficult learning curve. But I think it's interesting to consider that "the type system should deal with lifetimes" isn't really a baked-in opinion that Rust has, as much as it is the necessary complexity stemming from the other opinions above.
  - ccbccccbbcccbb 4y ago
    Compared to the tyrannical Rust, maybe.
  - deleted 4y ago
    [deleted]
  - Comevius 4y ago
    Opinionated in the context of programming languages usually means that the language forces it's own abstractions on you, you have to work with and around them. Zig is not like that, it's pretty much just C, but simpler, ergonomic. It's design is a reasonably simple, portable abstraction of contemporary hardware. It gives you all the power to come up with your own abstractions on top of that.
- lillecarl 4y ago
  I have no idea what I'm talking about, but rust can also be introduced gradually, and async isn't a language feature the kernel will use, actually the kernel will probably not even use the standard library because of how rust assumes it'll never run out of RAM.
  - varajelle 4y ago
    > and async isn't a language feature the kernel will use Why not thought? Lots of drivers could benefit from async to simplify their state machine as they wait for interrupt for example.
    - monocasa 4y ago
      Async is very good for only a specific kind of of state machine graph that isn't nearly as prevalent outside of network services.
    - Matthias247 4y ago
      One could try to use it for those use-cases, but it probably warrants some investigation if it's actually the best possible solution for the problem. The kernel has some different properties than userspace - e.g. context switches between kernel threads can already be cheap, which minimizes some of the reasons for using async/await. Then allocations for continuations using in-kernel slab allocators might also be cheaper then in userspace, whereas placing huge objects (Future)s on the stack (preferred mode of Rust Future composition) might be more expensive with tiny kernel stacks. I guess it might be worth to do experiments for some use-cases to see how it actually would work out.
- fathyb 4y ago
  Rust is mainly introduced to the kernel to allow writing safer drivers, which makes a lot of sense considering a crashing driver likely means a crashing computer.
  - easytiger 4y ago
    I've ran Linux (various) for near on 20 years and ran it on hundreds servers for 15. I've only ever hit one such crash for an external piece of custom hardware with a noddy kernel module. Plenty of crashing kernel modules yea.
    - deleted 4y ago
      [deleted]
    - ISV_Damocles 4y ago
      Both of statements can be true, though. Developers skilled enough / brave enough to write kernel drivers can be very careful about not leaking memory or mismanaging the hardware in question, and Rust can make that job much easier by being pedantic about memory mistakes or type misuses (with custom types that are validated at compile time but no runtime overhead). I've worked on C and Rust codebases, though nothing near as complex as the Linux kernel, and I'm excited for this change as it will reduce the burden on the kernel developers to reach the same quality output, so we either get drivers faster, or drivers for hardware we wouldn't have otherwise received, or both. As far as the fear of Rust kernel drivers that don't compile with GCC's Rust frontend, I trust Linus to keep the bar high on letting this feature in, and that kernel drivers accepted into the tree compile with just GCC as they always have. Third-party drivers may not, but that's also true today if someone wrote a driver that only compiled with LLVM. This doesn't really happen in practice as it goes against the path-of-least-resistance for the developer: they'd have to switch their toolset out when working on that driver vs everything else, and the auto-building by DKMS would probably fail on them if they used it during development -- all of the conventions used by the rest of the kernel infrastructure will keep them in line.
    - jeroenhd 4y ago
      I've run into many Linux driver bugs, usually for video drivers but sometimes for other components. On one laptop, AMD's kernel driver corrupted every third boot for a while, though that's been fixed. It's still dumping error messages and failures during boot but other than that it seems to work fine. On my new laptop, the kernel didn't even support my audio interface for a while. There was a bug with Intel GPUs that was unfixed for at least three kernel versions where plugging in an external monitor over an HDMI-to-Displayport adapter would reliably freeze the system the moment the kernel tried to modeset. That's finally been fixed from what I can tell, I believe it had something to do with a change to an NFS driver somehow. Server hardware often doesn't need complex or bleeding edge kernel modules. You don't need sound or video, you don't need framebuffer resolutions, you don't even need that much in terms of keyboard compatibility. It's a lot easier to run a kernel of the most complex hardware out there isn't hooked up to your system. That doesn't mean Linux is bug free, it merely means that the kernel code for the limited hardware of your choice has been maintained well. The real challenge for Linux or any kernel really is to run reliably on a laptop with an uncommon variation of common hardware, preferably sold for only a few months. That's where the real bugs come in.
- jeroenhd 4y ago
  Zig isn't finished yet. Rust has stable language features. You also don't need async in many if not most cases, especially if you're writing kernel code. I wouldn't want to use a kernel module that pulls in all of tokio/reqwest/hyper just like I don't want a kernel module that links against openssl. Async makes a lot of sense for userland code, but not so much for kernel code. I haven't seen async get used in any demo for kernel Rust modules and I doubt it'll happen anyway. Looking at a comparison between common kernel structures and theoretical Rust implementations of those (like on https://security.googleblog.com/2021/04/rust-in-linux-kernel.html https://security.googleblog.com/2021/04/rust-in-linux-kernel...) I think the kernel can get improved security and reliability from Rust without any "fancy" Rust. Just the basic type system improvements, nullability improvements and explicit checks will be enough for some real benefits.
  - WesolyKubeczek 4y ago
    > You also don't need async in many if not most cases, especially if you're writing kernel code. Have you seen how much communication with the hardware in drivers is actually very asynchronous? It’s all hand rolled C, of course, but there’s a lot of it. But look at the bright side: people likely won’t be enjoying hand-rolling asynchronous Rust since language-level primitives exist, so maybe there will be enough pressure and enough of use case diversity to make a more solid implementation that doesn’t suck, or sucks way less than the current one.
    - wongarsu 4y ago
      Currently the rust ecosystem is rapidly moving towards treating tokio as the default-and-only async runtime. If the linux kernel community establishes an async runtime tuned for embedded/kernel use cases that could bring some much needed diversity and speed up the process of making async ergonomic and less bolted-on.
    - nomel 4y ago
      > It’s all hand rolled C What do you consider "hand rolled"? The kernel has extensive support for these use cases since, as you said, hardware is usually async. Async with hardware is rarely tangled, from my limited experience. It's usually event driven.
- dundarious 4y ago
  I love zig, but neither dev nor stable releases are stable enough yet. Rust nightly builds are quite stable.
- belter 4y ago
  Zig case is not compelling enough: https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
- busterarm 4y ago
  The zig community never made a huge fuss and initiated a mexican standoff by stating their refusal to continue working in C.
- Tuna-Fish 4y ago
  What value would Zig provide to the kernel? The reason Rust is interesting in the space is the memory safety without a GC. Zig doesn't have that.
  - azakai 4y ago
    Zig's safety is lower than Rust's, that's true, but it is still a very big improvement over C, so a case could be made for it in principle. But of course in practice Zig is not stable enough to consider that yet. Anyhow, this isn't all or nothing: a case could also be made one way or the other about how much 'unsafe' to allow in Rust in the kernel. It's a question of tradeoffs.
- pornel 4y ago
  The "async is bad" meme is getting old. Someone has written an article about JS's limitation (which Rust doesn't have) and how they don't like C# syntax, and it gets endlessly slapped on every language as a vague notion of "colors". Async in Rust is incredibly well designed, and works very well for such a low-level design that minimizes heap allocations and virtual dispatch. Rust intentionally prefers locally explicit syntax for things that affect control flow, and wants to be back-end agnostic without a runtime, which goes against implicit built-in "colorless" magic.
- kzrdude 4y ago
  Zig would be if they wanted "C and generics and compile time evaluation", but maybe that does not seem compelling enough to the kernel.
- goodpoint 4y ago
  If anything, Nim would be an excellent candidate because it compiles to C, is memory safe and has no GC anymore.
jeroenhd 4y ago
I like Rust and I'd love to see it in the Linux kernel, but not before the GCC+Rust issues are all fixed. You shouldn't need non-GCC compilers to compile Linux and from what I can tell there isn't any GCC Rust compiler that's fully equivalent to the standard Rust compiler just yet. They say that Rust support is optional, but when the first big driver gets written in Rust it'll become mandatory. So either the Rust integration will fail and nothing important will get written in it, or it won't be optional. I'm not sure what comfort that's supposed to bring.
- selckin 4y ago
  Or that then gives people the motivation to work on gcc, have to solve the chicken-egg
- superkuh 4y ago
  Yup. And if you have to use the rustc compiler that means you cannot use the rustc compiler from your repositories. Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. They just assume you'll curl | rustup.whatever and install a new version of rustc every month from a third party website like every single Rust guide suggests. That's not optimal for the linux kernel. But maybe kernel dev types won't be as bad as the typical bleeding edge rust dev. And given that rapid rate of change in Rust, I don't see how GCC can ever keep up. Maybe in 10 years when Rust is more stable.
  - jcranmer 4y ago
    > Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler.
3836293648 4y ago
I really like rust, but I really don't like how much adoption it's getting. Rust is better than basically everything else out there, but it still really feels like a stepping stone language during a time of rapid language development. Even single threaded synchronous rust has its issues and it really feels like one or two more steps will get us to a significantly better place and getting rust adopted everywhere will just come and bite us in the end. Also, GCC should fix their stupid libjitgcc so new languages can use it reasonably instead of making everyone use llvm and then complain that there is no gcc implementation
- kllrnohj 4y ago
  So you know rust is the best fit, but you don't like it because of... vague reasons? Rust is the first compelling systems language since C++. This isn't an area with much attention paid to it. What is this a stepping stone towards? Zig is the only other thing that seems to get brought up, but it's not bringing any new ideas to the table. Certainly nothing close to what Rust is doing with the lifecycle checker. But why should Linux, or anyone really, let future promises block meaningful improvements today? If something comes along that's better than Rust for this, then another adoption/migration process can happen.
  - lostmsu 4y ago
    Rust needs better debugging support. A huge gap is inability to call arbitrary trait methods in expression evaluators. The issue is really starting considering you can't even call Debug's fmt.
    - monocasa 4y ago
      Kernel developers aren't using a repl, and in fact straight up were hostile to kgdb to even attach a debugger for a long time.
  - 3836293648 4y ago
    Maybe it's because I just started paying attention recently, but I'm seeing new approaches to the memory safety issue on r/ProgrammingLanguages every other week. Just off the top of my head, Vale looks interesting. But it's clearly under active research, even if it's not super visible
IYasha 4y ago
This is my humble opinion, but kernel shouldn't be a place for language diversity. Even code comments should be standardized for such critical and complex project with so many participants.
- speed_spread 4y ago
  Adding bindings for a second language after 25 years is not what I'd call "diversity".
  - ansible 4y ago
    And being stuck forever with a language that was invented over 50 years ago doesn't seem like a good idea either. If we want to take full advantage of the last half-century of PL research, we should just abandon Linux at some point and go with a completely new codebase instead? (Actually, that sounds kinda good to me, but I get why that may not be the best decision.)
    - tsujp 4y ago
      I feel like the crux of your argument here is that because C is 50 years old and research into programming languages has occurred in that same 50 year period that C is now automatically bad. What if there's nothing wrong with its intended purpose? The wheel has been around for some time, there has been research into other axle-mounted components surely we replace the wheel then? I don't understand the "it's old therefore bad" argument.
      - ahtihn 4y ago
        > What if there's nothing wrong with its intended purpose? But there is. See the long, long, so very long list of vulnerabilities caused by incorrect memory management.
      - Banana699 4y ago
        C is, in fact, bad. The moment it was released. It's so bad that one of the designers of Algol once quipped "Algol60 was an improvement over many of its predecessors, and many of its successors"[1], I had no doubt C was at the forefront of his mind when he said that. It was already a decade old when it was first released. Its wide use is a textbook example of path dependence and fashion worship that plagues software engineering, because it was distributed freely along with Unix, and Unix was the hot new free thing. GP was just emphasizing how old and crumbling that fossil is with the 50 years old remark. >What if there's nothing wrong with its intended purpose And what, exactly, is its intended purpose ? It was to rewrite a 10K LOC kernel maintained by a core team of 3 developers from PDP-7 assembly, in an age before the personal computer and the internet. It was literally created as an ad hoc, bug ridden and unspecified implementation, starting with the thinnest dressing over assembly and adding the absolute bare minimum required for a human to write ~10K LOC without gouging their own eyes off. There is plenty wrong with it. >I don't understand the "it's old therefore bad" argument. It's easy. Fields where there are progress invalidates and supersede their own widsom. You wouldn't go to a doctor trained 50 years ago if you could help it. You wouldn't drive a car made 50 years ago. The only fields where that's not the case is stagnating one, like building houses or making furnitures. Things where 'progress' consists of irrelevant-to-quality changes. Programming language design is in the first category, and not the second. Especially in the period from 1975 to 2000, it learned and discovered so much that languages made before that period might as well be cave man scribbling on cave walls. [1] https://quotepark.com/quotes/1741351-c-a-r-hoare-about-algol-60-here-is-a-language-so-far-ahead-o/ https://quotepark.com/quotes/1741351-c-a-r-hoare-about-algol...
tmountain 4y ago
Does anyone have context on how Rust will make its way into the kernel? I'd imagine the initial motions will be pointed towards allowing Rust code to build alongside the existing C codebase without friction. Is the intent to incrementally introduce new modules and subsystems in Rust after that? Is there an end goal to rewrite everything in Rust?
- Tuna-Fish 4y ago
  The initial project is to build a shim out of unsafe rust that allows drivers to be written in entirely safe rust. Nothing else is targeted yet.
  - tmountain 4y ago
    Ah, okay, that makes sense.
- kryptiskt 4y ago
  I'm pretty sure that something like Android would start out as the first users, as they are interested and it doesn't run on any architecture that lacks Rust. There is no plans to bring it into the core of Linux.
  - nicoburns 4y ago
    That and Asahi Linux (which similarly only targets hardware with good Rust support). The developer who has been working on reverse engineering the Apple Silicon GPU seems to be very seriously considering writing the linux kernel driver in in Rust.
cmrdporcupine 4y ago
As other commenters have poked at; I'd hope that if Rust is going into the kernel (even if just for drivers), that means it's hopefully hopefully started to "calm down" as a language. At least in regards to the features that affect kernel-level development. Stabilizing that doesn't preclude active development in things like async or in the standard library (both of which I'd expect not to see much or any use in the kernel.) But I'd hope for decent work towards backwards and forwards compatibility in the set of language features used there.
- mllllv 4y ago
  It hasn’t. Rust is 12 years old, has no specification, incomplete documentation, a borrow checker that won’t allow some valid code today but may allow that same code tomorrow, and a level of complexity that is seriously next level. It’s about as calm as C++ on cocaine in my opinion.
  - phendrenad2 4y ago
    I expect that Rust will kind of fork, like Python 2.x vs 3.x (remember that?). We'll have "stable Linux rust" and "move-fast-and-break-things meme Rust". Those of us who value stability will say "Thank you Linus Torvalds" and just use the "Linux rust" for everything.
    - nindalf 4y ago
      Could you give an example of a Rust release breaking existing compiling code? The Rust Project goes to great lengths to avoid this. For example, before every release they try to compile every open source Rust codebase with the release candidate compiler.
      - steveklabnik 4y ago
        There have been a few. It often comes down to something that was previously unsound being made an error. There’s been long deprecation periods when this happens. The fact that it’s hard to even remember that these things have happened is a testament to how rarely it happens and how well the breakage is handled.
mllllv 4y ago
dgb23 4y ago
EDIT: It is very bit unfortunate that my general/off-topic comment is currently the most upvoted. I was not commenting on the Linux integration specifically. I'm a _novice and hobbyist_ when it comes to Rust. For example this comment https://news.ycombinator.com/item?id=31849071 https://news.ycombinator.com/item?id=31849071 is much more interesting and on topic. --- I want to provoke a little bit, but I'm genuinely curious about the following: I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean: - Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language. - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem. - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with. - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making. I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?
- bragr 4y ago
  I'd encourage you to go read the project docs in the kernel for this. This rust project has been ongoing for years and I believe the documentation and discussion there addresses all the issues you raise. This is not a knee jerk "fashionable" decision.
- icambron 4y ago
  What’s your complaint about the question mark operator?
PointyFluff 4y ago
There's a lot of commenters here who have no idea how rust works, apparently.
fxttr 4y ago
I really have mixed feelings about that, but I am really curious to see what's happening. Some people also experimented with some kernel modules written in Rust on FreeBSD. If rust + linux is a success story, maybe FreeBSD could learn from it and adopt some ideas.
b20000 4y ago
i hope this never happens. if it does then i will lose all interest in ever contributing.
- webkike 4y ago
  Okay, so?
- dagmx 4y ago
  So you don't contribute now, and you want people to not do so something on the off chance you contribute something in the future, that is of more value than this delivers?
  - b20000 4y ago
    you don’t know whether i contribute or not. introducing another language will create additional barriers for new driver developers. the kernel itself is already complicated enough and the focus should be on better documentation for new developers and a more welcoming attitude in general to improving (read simplifying) APIs like ALSA-SoC, for example. and please don’t tell me that the docs in the kernel tree are good enough. as a device creator, i look at this from a completely different and more practical perspective than those who are obsessed about programming languages. in the end the kernel serves the hardware community and is not some kind of programming utopia to prove how smart you are.
    - webkike 4y ago
      How will it add new barriers? You can still program your drivers in C.
      - b20000 4y ago
        no, because sooner or later i will need to touch rust code when i work on drivers which means i need to learn the language and its constructs. i then have to maintain and keep up that know-how which adds more cost to my business. and the kernel is not going to become a 100% rust code base anytime soon.
sdfhdhjdw3 4y ago
Could someone explain to me why you would want to add Rust to the kernel, without using the word "safe".
- varajelle 4y ago
  Convenience of using zero-cost abstractions to get the same things done faster/easier?
  - sdfhdhjdw3 4y ago
    That's the guiding design principle of C++.
- webkike 4y ago
  Rust is more fun to program in than C. I was a pure C guy before I learned Rust.
  - dieortin 4y ago
    Surely being fun is not the best reason to add a language to a kernel.
    - webkike 4y ago
      Well, the OP took one of them away, and other people are pointing out other reasons. It’s just one reason. But maybe I can elaborate a little further: it’s as fast as C, but more fun.
    - pornel 4y ago
      Linus has commented that using C may eventually be an obstacle to attracting new contributors. Rust is attracting new developers and gaining mindshare. From Rustaceans' perspective C looks tedious and antiquated — not fun to work on.
      - sdfhdhjdw3 4y ago
deleted 4y ago
[deleted]
DesiLurker 4y ago
can someone eli5 why rust is okay but not c++11 variants?
- Arkanum 4y ago
  My limited understanding is that rust provides significant advantages in terms of memory safety[1], that should reduce the chance of errors and bugs, whilst c++11 does not provide these same advantages. [1] Comparison of memory safety of c vs Zig vs Rust (from elsewhere in the comments): https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
- boris 4y ago
  C++ burnt through a lot of good will in the C++98 era where it was admittedly a hot mess (and all the compilers where buggy dumpster fires). Now on one hand we have people who publicly and loudly swore off touching C++ ever again based on this experience (and even more people parroting the “C++ is a mess” statement without any experience) and on the other the excitement of Rust with all the hype making people invest a large amount of effort into learning it.
- jcranmer 4y ago
  Rust's design has given more thought for how to work in the kind of programming environment that the Linux kernel sits in than C++ (even C++11) has. Specifically (and this is no longer quite eli5), Rust's freestanding mode--working without a standard library--is somewhat fuller and more fleshed out than the C++ freestanding mode. Now, the sibling comment that points out that C++ gained a bad reputation pre-C++11 is probably a bigger reason for it not being seriously considered whereas Rust is, but there are some technical reasons where Rust does better than C++.
- woodruffw 4y ago
  'jcranmer gave a good summary, but to add one or two more points: * It's very difficult to predict allocation patterns in C++ (even modern variants) from just the source code. An innocent looking object allocated on the stack might have a nontrivial constructor with all kinds of side effects. Rust, while being slightly less explicit than C, is much more explicit than C++. * Modern C++ doesn't actually play that nicely with C. C++'s aliasing rules and casting rules keep getting more and more strict, whereas kernel programming lends itself to a lot of "bag-of-bytes-to-struct"-style programming. It would be very unfortunate if adding a C++ compiler to the kernel's build broke pre-existing C code by detecting UB in the context of C++ and decided to simply erase it.
titzer 4y ago
If the internal APIs of the Linux kernel were boiled down to WebAssembly, then many kernel modules and drivers could be written in any language and cheaply isolated, making it harder, maybe impossible to corrupt kernel memory. IMHO that would lead to a more modular, robust kernel with lots of options for programming it, without resorting to a full microkernel design that has costly IPC.
- Skunkleton 4y ago
  You would be interested to know that this already exists in the form of BPF.
  - titzer 4y ago
    With Wasm you could use any fully-featured programming language that compiles to Wasm, rather than severely-restricted and stylized C with a single toolchain that can generate BPF bytecode. Wasm has a formal specification and many high-performance implementations with near-native performance. BPF predated Wasm by a lot, yet not being a general purpose bytecode, hasn't had the engineering time invested that Wasm has.
    - born-jre 4y ago
      from my limited understanding bpf is not general propose by design, like disallowing infinite loops etc. otherwise people have been designing competent bytecode/vm since 90's. wasm kernel extension does sounds nice, especially after the meltdown and spectre.
- deleted 4y ago
  [deleted]
enriquto 4y ago
That's great. But please, no cargo! It would be horrifying! Also, having rust in a serious project like linux, (and omitting all the cargo madness), would be a great thing for the language.
- steveklabnik 4y ago
  They're not using Cargo.
  - enriquto 4y ago
    So happy to hear that! I hope this starts a tradition of cargo-less rust that is sorely missing. Rationale: just like Rust does not let you segfault, a decent build system should not let you download shit from the internet. Much less so, without asking you explicit permission. Much less so, silently and by default.
    - steveklabnik 4y ago
      I strongly disagree on every count, but I’m glad you’re happy.
    - mllllv 4y ago
      Totally agree. Not sure when downloading millions of lines of random code from the internet and executing it with essentially full permissions became a programmer virtue.
    - SAI_Peregrinus 4y ago
      Make lets you download shit from the internet.
      - enriquto 4y ago
        > Make lets you download shit from the internet. ...sure, by specifying the whole url and calling an external program where the actual shit downloading happens. The same as bash, C and so on. Of course, it is in very bad taste to do so, and by no means a standard or even common thing to do when using makefiles. Maybe it would be OK if cargo let you download code, after giving it a sort of "unsafe" flag or something. But the current behavior is just bonkers.
adamius 4y ago
Lua would be good. Device drivers need not be all about high performance especially for initial development. Lua would be fast enough for plenty of purposes.
- nequo 4y ago
  NetBSD has Lua support.[1] Unfortunately there doesn't seem to be a lot of published material on it. One interesting application I found was secmodel_sandbox[2] which used it to implement something similar to AppArmor. [1] https://www.netbsd.org/~lneto/bsdconbr15.pdf https://www.netbsd.org/~lneto/bsdconbr15.pdf [2] https://github.com/smherwig/netbsd-sandbox https://github.com/smherwig/netbsd-sandbox
  - phendrenad2 4y ago
    FreeBSD also.
    - nequo 4y ago
      My understanding is that FreeBSD only uses Lua in the bootloader. Has it made its way into the kernel too?
  - deleted 4y ago
    [deleted]
adwn 4y ago
Huh. I submitted this story yesterday [1], and it hardly got any traction. Weird. Is there a "preferred" time to post HN submissions? [1] https://news.ycombinator.com/item?id=31832081 https://news.ycombinator.com/item?id=31832081
- narimoney 4y ago
  why does it matter?
  - adwn 4y ago
    If I've found a story which I think would be of interest to many people, it makes sense to submit it in a way that maximizes the potential viewership.
- manx 4y ago
  Because of feedback loops in the ranking algorithm, you need to be a bit lucky. I described this in more detail here: https://felx.me/2021/08/29/improving-the-hacker-news-ranking-algorithm.html https://felx.me/2021/08/29/improving-the-hacker-news-ranking...
ThinkBeat 4y ago
I think this is a bad idea or at least far too soon. In my opinion the Rust language and eco system is not yet at the stability of C. I feel certain that mixing two different languages inside the kernel will give all new and challenging errors to debug. Also it is the fallacy of sunken cost. So much work has gone into the Linux kernel, but efforts should be made to replace it. What I would like to see is a project to create a new and modern kernel, taking a lot of what has been learned by the "prototype" Linux kernel and create something new and better. It would also be free to take full advantage of the language improvements between Rust and C. Sure it would take a lot of time, but I think it is time well invested, instead of slowing trying to port the current Linux kernel to Rust.
- mijoharas 4y ago
  > So much work has gone into the Linux kernel, but efforts should be made to replace it. Plenty of people are working on new kernels and operating systems both by hobbyists and companies (c.f. Redox[0], Fuscia (zircon kernel[1], e.t.c.). The main problem is that linux is an incredibly well developed piece of software, so it will take a very long time for anything to reach feature parity. > instead of slowing trying to port the current Linux kernel to Rust. I don't think anyone is suggesting to try and port the current kernel to Rust (and I'm fairly sure any suggestions in that direction would be met with a hard no from linus.) The current suggestion is just to allow language bindings to facilitate the writing of drivers in rust. Even looking to the future which could see some critical components of the kernel written in rust, I don't think anyone is suggesting that the entire kernel should be ported, since that's a monumental task (and suffers from the exact same issue as above, for questionable benefit). [0] https://www.redox-os.org/ https://www.redox-os.org/ [1] https://fuchsia.dev/fuchsia-src/concepts/kernel https://fuchsia.dev/fuchsia-src/concepts/kernel
tamrix 4y ago
Time to fork? I'm going to call the new c only Linux cinux

392 points by FPGAhacker 4y ago

Pardon my ignorance, but given the complexity of Rust, the incoherence of the async story etc, wouldn't something like Zig be a more reasonable choice for Linux, with its ability to be introduced gradually etc?

usrn 4y ago
I think zig is a little too opinionated.
- vkazanov 4y ago
  It is, indeed, opinionated. It's also small and easy. Rust is superopinionated. Big and complex as well.
  - usrn 4y ago
    Yeah I'm not a fan of Rust either. It has some great ideas though. Part of me wants to try writing my own language after I finish my current side project.
    - jeroenhd 4y ago
      You may be interested in Jakt, an experimental language written for SerenityOS. It has some very Rust-like festures for memory safety but no borrow checker or async (at least, not at the moment). Currently, it compiles into C++ as it's written specifically for an entire operating system written in C++ but I can see native compilation becoming an option down the line. It's far from stable but it's worth looking at: https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt
  - 127 4y ago
    Writing multi-line strings in Zig is not easy.
    - kristoff_it 4y ago
      I really don't understand why people have issues with Zig's multiline syntax. \\I really don't \\understand why people \\have issues with \\Zig's multiline syntax
      - lostmsu 4y ago
        I never used Zig, but used many other languages, and that looks better than most which don't have line prefix like \\: in languages that don't need it there is confusion about significance of whitespace in the beginning of 2nd+ lines.
        kristoff_it 4y ago
        Yep, that's precisely what that sintax solves, and also makes it easier to build a grammar for it (think of editor syntax highlighting for example) because the multiline marker is repeated in every line, instead of being a contextual marker. This is the same reason why Zig doesn't have dedicated multiline comment syntax.
      - 127 4y ago
        - Can't easily indent - Can't easily copy paste - Can't easily edit - Looks ugly - Harder to read
    - vkazanov 4y ago
      Huh? It might be slightly wordy, but otherwise very simple and easy for both people and computers to read. Even a primitive editor with primitive highlighting can make the syntax painless. Reasoning: https://github.com/ziglang/zig/issues/162 https://github.com/ziglang/zig/issues/162
  - oconnor663 4y ago
    Rust definitely has its opinions and its chosen complexities. I'd point to the way global allocators are used by default (opinionated) and the way trait coherence rules work (opinionated and kind of complicated). That said, I think a lot of the complexity of Rust is actually fallout from a relatively small number of design choices: - programs ought to be UB-free by default, and overriding those defaults should be rare - mutation is allowed, including shared mutation across threads - runtime assumptions similar to C and C++, i.e. no garbage collector, and a useful subset of the lanugage doesn't require heap allocation Given those requirements (in short, a "safe systems programming language"), I think you very quickly find yourself needing 1) lifetimes, 2) the no-mutable-aliasing rule, and 3) move semantics. Those things contribute a lot of the "feel" of Rust, and probably the majority of the difficult learning curve. But I think it's interesting to consider that "the type system should deal with lifetimes" isn't really a baked-in opinion that Rust has, as much as it is the necessary complexity stemming from the other opinions above.
- ccbccccbbcccbb 4y ago
  Compared to the tyrannical Rust, maybe.
- deleted 4y ago
  [deleted]
- Comevius 4y ago
  Opinionated in the context of programming languages usually means that the language forces it's own abstractions on you, you have to work with and around them. Zig is not like that, it's pretty much just C, but simpler, ergonomic. It's design is a reasonably simple, portable abstraction of contemporary hardware. It gives you all the power to come up with your own abstractions on top of that.
lillecarl 4y ago
I have no idea what I'm talking about, but rust can also be introduced gradually, and async isn't a language feature the kernel will use, actually the kernel will probably not even use the standard library because of how rust assumes it'll never run out of RAM.
- varajelle 4y ago
  > and async isn't a language feature the kernel will use Why not thought? Lots of drivers could benefit from async to simplify their state machine as they wait for interrupt for example.
  - monocasa 4y ago
    Async is very good for only a specific kind of of state machine graph that isn't nearly as prevalent outside of network services.
  - Matthias247 4y ago
    One could try to use it for those use-cases, but it probably warrants some investigation if it's actually the best possible solution for the problem. The kernel has some different properties than userspace - e.g. context switches between kernel threads can already be cheap, which minimizes some of the reasons for using async/await. Then allocations for continuations using in-kernel slab allocators might also be cheaper then in userspace, whereas placing huge objects (Future)s on the stack (preferred mode of Rust Future composition) might be more expensive with tiny kernel stacks. I guess it might be worth to do experiments for some use-cases to see how it actually would work out.
fathyb 4y ago
Rust is mainly introduced to the kernel to allow writing safer drivers, which makes a lot of sense considering a crashing driver likely means a crashing computer.
- easytiger 4y ago
  I've ran Linux (various) for near on 20 years and ran it on hundreds servers for 15. I've only ever hit one such crash for an external piece of custom hardware with a noddy kernel module. Plenty of crashing kernel modules yea.
  - deleted 4y ago
    [deleted]
  - ISV_Damocles 4y ago
    Both of statements can be true, though. Developers skilled enough / brave enough to write kernel drivers can be very careful about not leaking memory or mismanaging the hardware in question, and Rust can make that job much easier by being pedantic about memory mistakes or type misuses (with custom types that are validated at compile time but no runtime overhead). I've worked on C and Rust codebases, though nothing near as complex as the Linux kernel, and I'm excited for this change as it will reduce the burden on the kernel developers to reach the same quality output, so we either get drivers faster, or drivers for hardware we wouldn't have otherwise received, or both. As far as the fear of Rust kernel drivers that don't compile with GCC's Rust frontend, I trust Linus to keep the bar high on letting this feature in, and that kernel drivers accepted into the tree compile with just GCC as they always have. Third-party drivers may not, but that's also true today if someone wrote a driver that only compiled with LLVM. This doesn't really happen in practice as it goes against the path-of-least-resistance for the developer: they'd have to switch their toolset out when working on that driver vs everything else, and the auto-building by DKMS would probably fail on them if they used it during development -- all of the conventions used by the rest of the kernel infrastructure will keep them in line.
  - jeroenhd 4y ago
    I've run into many Linux driver bugs, usually for video drivers but sometimes for other components. On one laptop, AMD's kernel driver corrupted every third boot for a while, though that's been fixed. It's still dumping error messages and failures during boot but other than that it seems to work fine. On my new laptop, the kernel didn't even support my audio interface for a while. There was a bug with Intel GPUs that was unfixed for at least three kernel versions where plugging in an external monitor over an HDMI-to-Displayport adapter would reliably freeze the system the moment the kernel tried to modeset. That's finally been fixed from what I can tell, I believe it had something to do with a change to an NFS driver somehow. Server hardware often doesn't need complex or bleeding edge kernel modules. You don't need sound or video, you don't need framebuffer resolutions, you don't even need that much in terms of keyboard compatibility. It's a lot easier to run a kernel of the most complex hardware out there isn't hooked up to your system. That doesn't mean Linux is bug free, it merely means that the kernel code for the limited hardware of your choice has been maintained well. The real challenge for Linux or any kernel really is to run reliably on a laptop with an uncommon variation of common hardware, preferably sold for only a few months. That's where the real bugs come in.
jeroenhd 4y ago
Zig isn't finished yet. Rust has stable language features. You also don't need async in many if not most cases, especially if you're writing kernel code. I wouldn't want to use a kernel module that pulls in all of tokio/reqwest/hyper just like I don't want a kernel module that links against openssl. Async makes a lot of sense for userland code, but not so much for kernel code. I haven't seen async get used in any demo for kernel Rust modules and I doubt it'll happen anyway. Looking at a comparison between common kernel structures and theoretical Rust implementations of those (like on https://security.googleblog.com/2021/04/rust-in-linux-kernel.html https://security.googleblog.com/2021/04/rust-in-linux-kernel...) I think the kernel can get improved security and reliability from Rust without any "fancy" Rust. Just the basic type system improvements, nullability improvements and explicit checks will be enough for some real benefits.
- WesolyKubeczek 4y ago
  > You also don't need async in many if not most cases, especially if you're writing kernel code. Have you seen how much communication with the hardware in drivers is actually very asynchronous? It’s all hand rolled C, of course, but there’s a lot of it. But look at the bright side: people likely won’t be enjoying hand-rolling asynchronous Rust since language-level primitives exist, so maybe there will be enough pressure and enough of use case diversity to make a more solid implementation that doesn’t suck, or sucks way less than the current one.
  - wongarsu 4y ago
    Currently the rust ecosystem is rapidly moving towards treating tokio as the default-and-only async runtime. If the linux kernel community establishes an async runtime tuned for embedded/kernel use cases that could bring some much needed diversity and speed up the process of making async ergonomic and less bolted-on.
  - nomel 4y ago
    > It’s all hand rolled C What do you consider "hand rolled"? The kernel has extensive support for these use cases since, as you said, hardware is usually async. Async with hardware is rarely tangled, from my limited experience. It's usually event driven.
dundarious 4y ago
I love zig, but neither dev nor stable releases are stable enough yet. Rust nightly builds are quite stable.
belter 4y ago
Zig case is not compelling enough: https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
busterarm 4y ago
The zig community never made a huge fuss and initiated a mexican standoff by stating their refusal to continue working in C.
Tuna-Fish 4y ago
What value would Zig provide to the kernel? The reason Rust is interesting in the space is the memory safety without a GC. Zig doesn't have that.
- azakai 4y ago
  Zig's safety is lower than Rust's, that's true, but it is still a very big improvement over C, so a case could be made for it in principle. But of course in practice Zig is not stable enough to consider that yet. Anyhow, this isn't all or nothing: a case could also be made one way or the other about how much 'unsafe' to allow in Rust in the kernel. It's a question of tradeoffs.
pornel 4y ago
The "async is bad" meme is getting old. Someone has written an article about JS's limitation (which Rust doesn't have) and how they don't like C# syntax, and it gets endlessly slapped on every language as a vague notion of "colors". Async in Rust is incredibly well designed, and works very well for such a low-level design that minimizes heap allocations and virtual dispatch. Rust intentionally prefers locally explicit syntax for things that affect control flow, and wants to be back-end agnostic without a runtime, which goes against implicit built-in "colorless" magic.
kzrdude 4y ago
Zig would be if they wanted "C and generics and compile time evaluation", but maybe that does not seem compelling enough to the kernel.
goodpoint 4y ago
If anything, Nim would be an excellent candidate because it compiles to C, is memory safe and has no GC anymore.

jeroenhd 4y ago

I like Rust and I'd love to see it in the Linux kernel, but not before the GCC+Rust issues are all fixed. You shouldn't need non-GCC compilers to compile Linux and from what I can tell there isn't any GCC Rust compiler that's fully equivalent to the standard Rust compiler just yet. They say that Rust support is optional, but when the first big driver gets written in Rust it'll become mandatory. So either the Rust integration will fail and nothing important will get written in it, or it won't be optional. I'm not sure what comfort that's supposed to bring.

selckin 4y ago
Or that then gives people the motivation to work on gcc, have to solve the chicken-egg
superkuh 4y ago
Yup. And if you have to use the rustc compiler that means you cannot use the rustc compiler from your repositories. Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. They just assume you'll curl | rustup.whatever and install a new version of rustc every month from a third party website like every single Rust guide suggests. That's not optimal for the linux kernel. But maybe kernel dev types won't be as bad as the typical bleeding edge rust dev. And given that rapid rate of change in Rust, I don't see how GCC can ever keep up. Maybe in 10 years when Rust is more stable.
- jcranmer 4y ago
  > Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility. Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler.

3836293648 4y ago

I really like rust, but I really don't like how much adoption it's getting. Rust is better than basically everything else out there, but it still really feels like a stepping stone language during a time of rapid language development. Even single threaded synchronous rust has its issues and it really feels like one or two more steps will get us to a significantly better place and getting rust adopted everywhere will just come and bite us in the end. Also, GCC should fix their stupid libjitgcc so new languages can use it reasonably instead of making everyone use llvm and then complain that there is no gcc implementation

kllrnohj 4y ago
So you know rust is the best fit, but you don't like it because of... vague reasons? Rust is the first compelling systems language since C++. This isn't an area with much attention paid to it. What is this a stepping stone towards? Zig is the only other thing that seems to get brought up, but it's not bringing any new ideas to the table. Certainly nothing close to what Rust is doing with the lifecycle checker. But why should Linux, or anyone really, let future promises block meaningful improvements today? If something comes along that's better than Rust for this, then another adoption/migration process can happen.
- lostmsu 4y ago
  Rust needs better debugging support. A huge gap is inability to call arbitrary trait methods in expression evaluators. The issue is really starting considering you can't even call Debug's fmt.
  - monocasa 4y ago
    Kernel developers aren't using a repl, and in fact straight up were hostile to kgdb to even attach a debugger for a long time.
- 3836293648 4y ago
  Maybe it's because I just started paying attention recently, but I'm seeing new approaches to the memory safety issue on r/ProgrammingLanguages every other week. Just off the top of my head, Vale looks interesting. But it's clearly under active research, even if it's not super visible

IYasha 4y ago

This is my humble opinion, but kernel shouldn't be a place for language diversity. Even code comments should be standardized for such critical and complex project with so many participants.

speed_spread 4y ago
Adding bindings for a second language after 25 years is not what I'd call "diversity".
- ansible 4y ago
  And being stuck forever with a language that was invented over 50 years ago doesn't seem like a good idea either. If we want to take full advantage of the last half-century of PL research, we should just abandon Linux at some point and go with a completely new codebase instead? (Actually, that sounds kinda good to me, but I get why that may not be the best decision.)
  - tsujp 4y ago
    I feel like the crux of your argument here is that because C is 50 years old and research into programming languages has occurred in that same 50 year period that C is now automatically bad. What if there's nothing wrong with its intended purpose? The wheel has been around for some time, there has been research into other axle-mounted components surely we replace the wheel then? I don't understand the "it's old therefore bad" argument.
    - ahtihn 4y ago
      > What if there's nothing wrong with its intended purpose? But there is. See the long, long, so very long list of vulnerabilities caused by incorrect memory management.
    - Banana699 4y ago
      C is, in fact, bad. The moment it was released. It's so bad that one of the designers of Algol once quipped "Algol60 was an improvement over many of its predecessors, and many of its successors"[1], I had no doubt C was at the forefront of his mind when he said that. It was already a decade old when it was first released. Its wide use is a textbook example of path dependence and fashion worship that plagues software engineering, because it was distributed freely along with Unix, and Unix was the hot new free thing. GP was just emphasizing how old and crumbling that fossil is with the 50 years old remark. >What if there's nothing wrong with its intended purpose And what, exactly, is its intended purpose ? It was to rewrite a 10K LOC kernel maintained by a core team of 3 developers from PDP-7 assembly, in an age before the personal computer and the internet. It was literally created as an ad hoc, bug ridden and unspecified implementation, starting with the thinnest dressing over assembly and adding the absolute bare minimum required for a human to write ~10K LOC without gouging their own eyes off. There is plenty wrong with it. >I don't understand the "it's old therefore bad" argument. It's easy. Fields where there are progress invalidates and supersede their own widsom. You wouldn't go to a doctor trained 50 years ago if you could help it. You wouldn't drive a car made 50 years ago. The only fields where that's not the case is stagnating one, like building houses or making furnitures. Things where 'progress' consists of irrelevant-to-quality changes. Programming language design is in the first category, and not the second. Especially in the period from 1975 to 2000, it learned and discovered so much that languages made before that period might as well be cave man scribbling on cave walls. [1] https://quotepark.com/quotes/1741351-c-a-r-hoare-about-algol-60-here-is-a-language-so-far-ahead-o/ https://quotepark.com/quotes/1741351-c-a-r-hoare-about-algol...

tmountain 4y ago

Does anyone have context on how Rust will make its way into the kernel? I'd imagine the initial motions will be pointed towards allowing Rust code to build alongside the existing C codebase without friction. Is the intent to incrementally introduce new modules and subsystems in Rust after that? Is there an end goal to rewrite everything in Rust?

Tuna-Fish 4y ago
The initial project is to build a shim out of unsafe rust that allows drivers to be written in entirely safe rust. Nothing else is targeted yet.
- tmountain 4y ago
  Ah, okay, that makes sense.
kryptiskt 4y ago
I'm pretty sure that something like Android would start out as the first users, as they are interested and it doesn't run on any architecture that lacks Rust. There is no plans to bring it into the core of Linux.
- nicoburns 4y ago
  That and Asahi Linux (which similarly only targets hardware with good Rust support). The developer who has been working on reverse engineering the Apple Silicon GPU seems to be very seriously considering writing the linux kernel driver in in Rust.

cmrdporcupine 4y ago

As other commenters have poked at; I'd hope that if Rust is going into the kernel (even if just for drivers), that means it's hopefully hopefully started to "calm down" as a language. At least in regards to the features that affect kernel-level development. Stabilizing that doesn't preclude active development in things like async or in the standard library (both of which I'd expect not to see much or any use in the kernel.) But I'd hope for decent work towards backwards and forwards compatibility in the set of language features used there.

mllllv 4y ago
It hasn’t. Rust is 12 years old, has no specification, incomplete documentation, a borrow checker that won’t allow some valid code today but may allow that same code tomorrow, and a level of complexity that is seriously next level. It’s about as calm as C++ on cocaine in my opinion.
- phendrenad2 4y ago
  I expect that Rust will kind of fork, like Python 2.x vs 3.x (remember that?). We'll have "stable Linux rust" and "move-fast-and-break-things meme Rust". Those of us who value stability will say "Thank you Linus Torvalds" and just use the "Linux rust" for everything.
  - nindalf 4y ago
    Could you give an example of a Rust release breaking existing compiling code? The Rust Project goes to great lengths to avoid this. For example, before every release they try to compile every open source Rust codebase with the release candidate compiler.
    - steveklabnik 4y ago
      There have been a few. It often comes down to something that was previously unsound being made an error. There’s been long deprecation periods when this happens. The fact that it’s hard to even remember that these things have happened is a testament to how rarely it happens and how well the breakage is handled.

mllllv 4y ago

dgb23 4y ago

EDIT: It is very bit unfortunate that my general/off-topic comment is currently the most upvoted. I was not commenting on the Linux integration specifically. I'm a _novice and hobbyist_ when it comes to Rust. For example this comment https://news.ycombinator.com/item?id=31849071 https://news.ycombinator.com/item?id=31849071 is much more interesting and on topic. --- I want to provoke a little bit, but I'm genuinely curious about the following: I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean: - Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language. - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem. - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with. - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making. I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?

bragr 4y ago
I'd encourage you to go read the project docs in the kernel for this. This rust project has been ongoing for years and I believe the documentation and discussion there addresses all the issues you raise. This is not a knee jerk "fashionable" decision.
icambron 4y ago
What’s your complaint about the question mark operator?

PointyFluff 4y ago

There's a lot of commenters here who have no idea how rust works, apparently.

fxttr 4y ago

I really have mixed feelings about that, but I am really curious to see what's happening. Some people also experimented with some kernel modules written in Rust on FreeBSD. If rust + linux is a success story, maybe FreeBSD could learn from it and adopt some ideas.

b20000 4y ago

i hope this never happens. if it does then i will lose all interest in ever contributing.

webkike 4y ago
Okay, so?
dagmx 4y ago
So you don't contribute now, and you want people to not do so something on the off chance you contribute something in the future, that is of more value than this delivers?
- b20000 4y ago
  you don’t know whether i contribute or not. introducing another language will create additional barriers for new driver developers. the kernel itself is already complicated enough and the focus should be on better documentation for new developers and a more welcoming attitude in general to improving (read simplifying) APIs like ALSA-SoC, for example. and please don’t tell me that the docs in the kernel tree are good enough. as a device creator, i look at this from a completely different and more practical perspective than those who are obsessed about programming languages. in the end the kernel serves the hardware community and is not some kind of programming utopia to prove how smart you are.
  - webkike 4y ago
    How will it add new barriers? You can still program your drivers in C.
    - b20000 4y ago
      no, because sooner or later i will need to touch rust code when i work on drivers which means i need to learn the language and its constructs. i then have to maintain and keep up that know-how which adds more cost to my business. and the kernel is not going to become a 100% rust code base anytime soon.

sdfhdhjdw3 4y ago

Could someone explain to me why you would want to add Rust to the kernel, without using the word "safe".

varajelle 4y ago
Convenience of using zero-cost abstractions to get the same things done faster/easier?
- sdfhdhjdw3 4y ago
  That's the guiding design principle of C++.
webkike 4y ago
Rust is more fun to program in than C. I was a pure C guy before I learned Rust.
- dieortin 4y ago
  Surely being fun is not the best reason to add a language to a kernel.
  - webkike 4y ago
    Well, the OP took one of them away, and other people are pointing out other reasons. It’s just one reason. But maybe I can elaborate a little further: it’s as fast as C, but more fun.
  - pornel 4y ago
    Linus has commented that using C may eventually be an obstacle to attracting new contributors. Rust is attracting new developers and gaining mindshare. From Rustaceans' perspective C looks tedious and antiquated — not fun to work on.
    - sdfhdhjdw3 4y ago

deleted 4y ago

[deleted]

DesiLurker 4y ago

can someone eli5 why rust is okay but not c++11 variants?

Arkanum 4y ago
My limited understanding is that rust provides significant advantages in terms of memory safety[1], that should reduce the chance of errors and bugs, whilst c++11 does not provide these same advantages. [1] Comparison of memory safety of c vs Zig vs Rust (from elsewhere in the comments): https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
boris 4y ago
C++ burnt through a lot of good will in the C++98 era where it was admittedly a hot mess (and all the compilers where buggy dumpster fires). Now on one hand we have people who publicly and loudly swore off touching C++ ever again based on this experience (and even more people parroting the “C++ is a mess” statement without any experience) and on the other the excitement of Rust with all the hype making people invest a large amount of effort into learning it.
jcranmer 4y ago
Rust's design has given more thought for how to work in the kind of programming environment that the Linux kernel sits in than C++ (even C++11) has. Specifically (and this is no longer quite eli5), Rust's freestanding mode--working without a standard library--is somewhat fuller and more fleshed out than the C++ freestanding mode. Now, the sibling comment that points out that C++ gained a bad reputation pre-C++11 is probably a bigger reason for it not being seriously considered whereas Rust is, but there are some technical reasons where Rust does better than C++.
woodruffw 4y ago
'jcranmer gave a good summary, but to add one or two more points: * It's very difficult to predict allocation patterns in C++ (even modern variants) from just the source code. An innocent looking object allocated on the stack might have a nontrivial constructor with all kinds of side effects. Rust, while being slightly less explicit than C, is much more explicit than C++. * Modern C++ doesn't actually play that nicely with C. C++'s aliasing rules and casting rules keep getting more and more strict, whereas kernel programming lends itself to a lot of "bag-of-bytes-to-struct"-style programming. It would be very unfortunate if adding a C++ compiler to the kernel's build broke pre-existing C code by detecting UB in the context of C++ and decided to simply erase it.

titzer 4y ago

If the internal APIs of the Linux kernel were boiled down to WebAssembly, then many kernel modules and drivers could be written in any language and cheaply isolated, making it harder, maybe impossible to corrupt kernel memory. IMHO that would lead to a more modular, robust kernel with lots of options for programming it, without resorting to a full microkernel design that has costly IPC.

Skunkleton 4y ago
You would be interested to know that this already exists in the form of BPF.
- titzer 4y ago
  With Wasm you could use any fully-featured programming language that compiles to Wasm, rather than severely-restricted and stylized C with a single toolchain that can generate BPF bytecode. Wasm has a formal specification and many high-performance implementations with near-native performance. BPF predated Wasm by a lot, yet not being a general purpose bytecode, hasn't had the engineering time invested that Wasm has.
  - born-jre 4y ago
    from my limited understanding bpf is not general propose by design, like disallowing infinite loops etc. otherwise people have been designing competent bytecode/vm since 90's. wasm kernel extension does sounds nice, especially after the meltdown and spectre.
deleted 4y ago
[deleted]

enriquto 4y ago

That's great. But please, no cargo! It would be horrifying! Also, having rust in a serious project like linux, (and omitting all the cargo madness), would be a great thing for the language.

steveklabnik 4y ago
They're not using Cargo.
- enriquto 4y ago
  So happy to hear that! I hope this starts a tradition of cargo-less rust that is sorely missing. Rationale: just like Rust does not let you segfault, a decent build system should not let you download shit from the internet. Much less so, without asking you explicit permission. Much less so, silently and by default.
  - steveklabnik 4y ago
    I strongly disagree on every count, but I’m glad you’re happy.
  - mllllv 4y ago
    Totally agree. Not sure when downloading millions of lines of random code from the internet and executing it with essentially full permissions became a programmer virtue.
  - SAI_Peregrinus 4y ago
    Make lets you download shit from the internet.
    - enriquto 4y ago
      > Make lets you download shit from the internet. ...sure, by specifying the whole url and calling an external program where the actual shit downloading happens. The same as bash, C and so on. Of course, it is in very bad taste to do so, and by no means a standard or even common thing to do when using makefiles. Maybe it would be OK if cargo let you download code, after giving it a sort of "unsafe" flag or something. But the current behavior is just bonkers.

adamius 4y ago

Lua would be good. Device drivers need not be all about high performance especially for initial development. Lua would be fast enough for plenty of purposes.

nequo 4y ago
NetBSD has Lua support.[1] Unfortunately there doesn't seem to be a lot of published material on it. One interesting application I found was secmodel_sandbox[2] which used it to implement something similar to AppArmor. [1] https://www.netbsd.org/~lneto/bsdconbr15.pdf https://www.netbsd.org/~lneto/bsdconbr15.pdf [2] https://github.com/smherwig/netbsd-sandbox https://github.com/smherwig/netbsd-sandbox
- phendrenad2 4y ago
  FreeBSD also.
  - nequo 4y ago
    My understanding is that FreeBSD only uses Lua in the bootloader. Has it made its way into the kernel too?
- deleted 4y ago
  [deleted]

adwn 4y ago

Huh. I submitted this story yesterday [1], and it hardly got any traction. Weird. Is there a "preferred" time to post HN submissions? [1] https://news.ycombinator.com/item?id=31832081 https://news.ycombinator.com/item?id=31832081

narimoney 4y ago
why does it matter?
- adwn 4y ago
  If I've found a story which I think would be of interest to many people, it makes sense to submit it in a way that maximizes the potential viewership.
manx 4y ago
Because of feedback loops in the ranking algorithm, you need to be a bit lucky. I described this in more detail here: https://felx.me/2021/08/29/improving-the-hacker-news-ranking-algorithm.html https://felx.me/2021/08/29/improving-the-hacker-news-ranking...

ThinkBeat 4y ago

I think this is a bad idea or at least far too soon. In my opinion the Rust language and eco system is not yet at the stability of C. I feel certain that mixing two different languages inside the kernel will give all new and challenging errors to debug. Also it is the fallacy of sunken cost. So much work has gone into the Linux kernel, but efforts should be made to replace it. What I would like to see is a project to create a new and modern kernel, taking a lot of what has been learned by the "prototype" Linux kernel and create something new and better. It would also be free to take full advantage of the language improvements between Rust and C. Sure it would take a lot of time, but I think it is time well invested, instead of slowing trying to port the current Linux kernel to Rust.

mijoharas 4y ago
> So much work has gone into the Linux kernel, but efforts should be made to replace it. Plenty of people are working on new kernels and operating systems both by hobbyists and companies (c.f. Redox[0], Fuscia (zircon kernel[1], e.t.c.). The main problem is that linux is an incredibly well developed piece of software, so it will take a very long time for anything to reach feature parity. > instead of slowing trying to port the current Linux kernel to Rust. I don't think anyone is suggesting to try and port the current kernel to Rust (and I'm fairly sure any suggestions in that direction would be met with a hard no from linus.) The current suggestion is just to allow language bindings to facilitate the writing of drivers in rust. Even looking to the future which could see some critical components of the kernel written in rust, I don't think anyone is suggesting that the entire kernel should be ported, since that's a monumental task (and suffers from the exact same issue as above, for questionable benefit). [0] https://www.redox-os.org/ https://www.redox-os.org/ [1] https://fuchsia.dev/fuchsia-src/concepts/kernel https://fuchsia.dev/fuchsia-src/concepts/kernel

tamrix 4y ago

Time to fork? I'm going to call the new c only Linux cinux