5 ms·

Sure, writing kernel code in a more modern language could be a big improvement in the short run (well, as soon as one can write the code, I guess). But what abo

• steveklabnik 6y ago
  > (no dependencies on experimental features of Rust, Unclear if this is a hard requirement, even if it is, it's stated to be feasible on the timescale of "less than a year". > support for all relevant architectures) This is already fulfilled; this is for drivers only, which are inherently platform-specific, and so only drivers that are usable on the supported platforms would be written. > there could well be a dozen different languages available that improve greatly on Rust As mentioned above, I doubt that this is true within a year, but beyond that, any new language is also going to have all of these same growing pains, but be a decade behind. When they're ready, they should be considered, but "don't do a good thing now because maybe, some unknown amazing thing might appear" isn't usually a good way to make decisions.
  • arp242 6y ago
    > > there could well be a dozen different languages available that improve greatly on Rust > As mentioned above, I doubt that this is true within a year, but beyond that, any new language is also going to have all of these same growing pains, but be a decade behind. When they're ready, they should be considered, but "don't do a good thing now because maybe, some unknown amazing thing might appear" isn't usually a good way to make decisions. This is true, but Linux is a long-term project, we don't know what the future will bring, but I'd be surprised if it wasn't still a mainstream kernel in 20 or even 40 years. It seems to me it would be wise to look at the future as well, and perhaps things are the wrong way around; rather than asking "what existing languages could work for the kernel?" the question should be "what would the ideal language for the kernel look like?" It always seemed to me that Rust is a bit of a strange choice for the Linux kernel; I can see why it has some appeal, but it's also a fairly large and complicated language. How "complex" or "minimal" a language should be is an old debate that we've all done at least a few times, so don't want to repeat it here; for my part, I feel comfterable with both approaches; I'm just as happy programming in Ruby as in Go for example (even though they're polar opposites in many ways), but both approaches come with their own set of advantages and downsides. I'm not so sure that a large and complex language is really the best fit for this particular purpose. For example writing a C compiler for a new architecture is comparatively easy whereas porting Rust to something new will be much harder. Given Linux's long-term prospects it might be wise to invest in an "ideal" language rather than a "it'll work" language. Then again, I don't work on Linux so what do I know :-)
    • geofft 6y ago
      Frankly, one of the best things we could do to help this hypothetical future language be adopted is to have precedent for Linux using another language. We're really trying two things here - getting Linux to use some Rust, and getting Linux to use some other language, with an independent compiler. That second part is pretty significant by itself (we've had discussions about build systems, compiler ABI bugs, etc.), and even if we were just trying to add C Except Different, it would be a major project on its own. Once we've figured out how to make them interoperate and what the ground rules are (architecture compatibility, where new development goes, whether the new language can be mandatory, release timeframes, etc.), a third language will be on much better-explored territory. (I do actually think that Rust is pretty close to ideal for the Linux kernel as it currently exists, though! As I argue in https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf / https://www.youtube.com/watch?v=RyY01fRyGhM https://www.youtube.com/watch?v=RyY01fRyGhM , a lot of Rust constructs happen to match idioms and abstractions that the kernel uses with C. But yes, there's a lot of research on both good kernels and good programming languages yet to be done.)
      • arp242 6y ago
        Right; going from n=1 to n=2 is usually a lot of work, but going on to n=3 and beyond after that is usually much easier. It's good this is finally been considered; there have been projects like this for decades but they never made much headway. I remember seeing this presentation about a memory safe driver framework over 10 years ago, and while it was functional (according to the authors) it never seemed to see much implementation (IIRC it generated C code, I can't recall the name of the project). There's also stuff like Cyclone[1], and I never understood why that never got any traction as it embodies more or less the same ideas as Rust (the homepage even recommends Rust now), and there's of course D, although the lack of adoption there can probably be explained by the licensing (D can run without a GC). [1]: http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/
        • ssokolow 6y ago
          As I understand it, it's because Cyclone's big advantage isn't what made Rust popular. It's that Rust combined a whole lot of attractive features in a single package, of which, memory safety without GC is only one.
• sinistersnare 6y ago
  "There may be something better in the future, so we shouldn't change anything ever" is not a very strong argument. No one thinks Rust is the end-all-be-all. They simply think that Rust is better than C, quite easily at that. And Rust does focus on correctness... If people wanted memory safety, almost any not-C/C++ language would be good enough. Rust's correctness story is wonderful, which is why I myself don't focus on the garbage-collector thing when talking about Rust. And C++ has been thoroughly rebuked by Linus, and his statements have only gotten stronger with time.
  • deleted 6y ago
    [deleted]
• ironman1478 6y ago
  Personally, I don't think C++ would give a similar improvement to Rust or a future competitor to Rust. C++ has a severe useability problem. Many companies have to really restrict what subset of C++ is used based on use cases. I don't know what contributing to the linux kernel is like, but I imagine having readable code really helps. Paring down C++ to the subset that gives measurable improvements while also being readable seems daunting. Where do you draw the lines? Will concepts be allowed, what about template heavy code and SFINAE? If you go down the C with classes route (which doesn't provide too much advantage), it might be easier to for existing devs to work on it, but if you go too far the other way, you could alienate a lot of people who contribute to the kernel already and don't have the time or will to understand the complex template deduction system of C++. Rust seems to be much more opinionated on how to do certain tasks, which might make it an easier to use for the kernel because there will be one way to do certain tasks. That's my read on things at least.
• deleted 6y ago
  [deleted]
• junon 6y ago
  This 100%. I've seen rust fans quote "correctness" without knowing what that word means, saying Rust gives it to you for free. It does NOT, and it conveys the wrong message. This comment getting downvoted is everything wrong with HN.
  • carols10cents 6y ago
    Can you link to Rust fans saying Rust gives you correctness for free? I've seen the opposite-- Rust folks interested in proofs and property tests and fuzzing as well as what Rust gives you for free, which they understand is not "correctness".
    • junon 6y ago
      This thread alone has a comment saying Rust allows you to write "correct" programs, when is wrong.