4 ms·

> I would like to see an example of a legitimate Linux Kernel module written in Rust that is in some form of use. Seriously this. I write an awful lot of kern

> I would like to see an example of a legitimate Linux Kernel module written in Rust that is in some form of use. Seriously this. I write an awful lot of kernel code. There's absolutely no way I'd try to convince folks to accept Rust code into the OS repository, where it will have to: - Be maintained for decades - Be ported to a litany of platforms, several of which may only have decent toolchains from the GCC department. - Vend stable ABI - Not require keeping a litany of compiler versions around just to keep older code building.

pcwalton 10y ago
> - Not require keeping a litany of compiler versions around just to keep older code building. Do you have a single example of this? We keep very close tabs on breakage in the wild even, and especially, for changes we were allowed to make (unlike say GCC, which happily breaks code if the language standard says the code never should have compiled in the first place). There are times when we've refused to make changes that we were allowed to make (because they were changes to unspecified behavior, which C/C++ has more of than Rust, and which GCC/Clang changes all the time) out of concern for breaking existing code. As far as I'm concerned, honestly, this is just FUD.
- teacup50 10y ago
  Your own release notes contain descriptions of breaking language changes. That may change as the language matures -- great. I keep an eye on Rust so that I can eventually try actually using it for kernel-level development work.
  - steveklabnik 10y ago
    Again, so do C compilers, so does Java, so does every language, even ones that "never break". C11 removed gets, for example.
    - teacup50 10y ago
      javac, gcc, and clang all support some form of -std=<lang_level>, and ABI/source interop between code that uses different language versions. The post-gcc 2.95 C++ ABI breakage was pretty suck, though. [edit] And please don't misinterpret my criticism as intentional FUD. I work on $MAJOR_OS and am achingly tired of writing C, so I keep my eye on Rust as one possible salvation, once it's had time to mature. It's just a very hard sell when there's no ABI stability, we're talking about code that's expected to last for decades, etc.
      - steveklabnik 10y ago
        It's all good. I hear you. We'll get there :) It took C what, 17 years or something to have ABI stability?
  - pcwalton 10y ago
    As I explained, those are only "breaking changes" in the sense that some code might break in practice, not that we changed the language definition. GCC did not provide a switch to get the old copy constructor behavior back when they made it stricter and broke my code.
pjmlp 10y ago
Hence why it is a failure trying to convince UNIX users to use anything other than C. C replacements will need to succeed in other OS not married with UNIX culture. Which means Swift, .NET Native, Java/C++, C++17, on the OSes from Apple, Google and Microsoft.
- teacup50 10y ago
  > Which means Swift, .NET Native, Java/C++, C++17, on the OSes from Apple, Google and Microsoft. You've seen where their OS code comes from, and what it's written in, right? Just to be very clear, I'm very well-versed in life outside C and imperative programming. This isn't "UNIX culture". This is "systems programming" culture, and it's simply pragmatic.
  - pjmlp 10y ago
    Yes I have seen where their OSes come from. Mac OS X and their predecessor might have an UNIX heritage, but C was always left for the very lowest layer. Already on NeXT the device drivers were written in Objective-C, being replaced by C++ on Mac OS X. Anyone paying attention to their Swift talks during the last two WWDCs knows where the boat is steering. Cris is quite clear in stating Swift should be usable in all scenarios where C is being used and Sierra already got some adoption in userland components like the dock and launch deamons, now rewritten in Swift. Microsoft has declared C89 as good enough with the future being C++ and .NET Native. The C runtime library was rewritten in C++ with extern C for the public symbols. The C99 compatibility and upcoming C11 are only done to the extent required by ANSI C++. For anything else there is clang. As of Windows 8, the device driver framework has been changed to C++ and there was a talk from Herb Sutter where he mentioned the plan was to migrate the kernel to compile with a C++ compiler. The idea of Core C++ Guidelines actually originated at Microsoft, before Bjarne and CERN guys got involved. Google doesn't allow native code on ChromeOS and on Android they make pretty clear that the NDK is just to make game developers happy and nothing else. They are all aware that C isn't going away tomorrow, but are driving efforts to make it as relevant in the future on their platforms as Assembly is today. When I started working in IT, the only OS written in C was UNIX. The language is not a sacred cow and the only thing preventing replacing it is the ubiquity of UNIX like OSes. OS not bound to the UNIX culture and POSIX compatibility are free to chose other language as their systems language. Not doing so, is usually a decision to cater to the status quo and ubiquity of existing developers and library (with their endless CVE entries).

pcwalton 10y ago

> - Not require keeping a litany of compiler versions around just to keep older code building. Do you have a single example of this? We keep very close tabs on breakage in the wild even, and especially, for changes we were allowed to make (unlike say GCC, which happily breaks code if the language standard says the code never should have compiled in the first place). There are times when we've refused to make changes that we were allowed to make (because they were changes to unspecified behavior, which C/C++ has more of than Rust, and which GCC/Clang changes all the time) out of concern for breaking existing code. As far as I'm concerned, honestly, this is just FUD.

teacup50 10y ago
Your own release notes contain descriptions of breaking language changes. That may change as the language matures -- great. I keep an eye on Rust so that I can eventually try actually using it for kernel-level development work.
- steveklabnik 10y ago
  Again, so do C compilers, so does Java, so does every language, even ones that "never break". C11 removed gets, for example.
  - teacup50 10y ago
    javac, gcc, and clang all support some form of -std=<lang_level>, and ABI/source interop between code that uses different language versions. The post-gcc 2.95 C++ ABI breakage was pretty suck, though. [edit] And please don't misinterpret my criticism as intentional FUD. I work on $MAJOR_OS and am achingly tired of writing C, so I keep my eye on Rust as one possible salvation, once it's had time to mature. It's just a very hard sell when there's no ABI stability, we're talking about code that's expected to last for decades, etc.
    - steveklabnik 10y ago
      It's all good. I hear you. We'll get there :) It took C what, 17 years or something to have ABI stability?
- pcwalton 10y ago
  As I explained, those are only "breaking changes" in the sense that some code might break in practice, not that we changed the language definition. GCC did not provide a switch to get the old copy constructor behavior back when they made it stricter and broke my code.

pjmlp 10y ago

Hence why it is a failure trying to convince UNIX users to use anything other than C. C replacements will need to succeed in other OS not married with UNIX culture. Which means Swift, .NET Native, Java/C++, C++17, on the OSes from Apple, Google and Microsoft.

teacup50 10y ago
> Which means Swift, .NET Native, Java/C++, C++17, on the OSes from Apple, Google and Microsoft. You've seen where their OS code comes from, and what it's written in, right? Just to be very clear, I'm very well-versed in life outside C and imperative programming. This isn't "UNIX culture". This is "systems programming" culture, and it's simply pragmatic.
- pjmlp 10y ago
  Yes I have seen where their OSes come from. Mac OS X and their predecessor might have an UNIX heritage, but C was always left for the very lowest layer. Already on NeXT the device drivers were written in Objective-C, being replaced by C++ on Mac OS X. Anyone paying attention to their Swift talks during the last two WWDCs knows where the boat is steering. Cris is quite clear in stating Swift should be usable in all scenarios where C is being used and Sierra already got some adoption in userland components like the dock and launch deamons, now rewritten in Swift. Microsoft has declared C89 as good enough with the future being C++ and .NET Native. The C runtime library was rewritten in C++ with extern C for the public symbols. The C99 compatibility and upcoming C11 are only done to the extent required by ANSI C++. For anything else there is clang. As of Windows 8, the device driver framework has been changed to C++ and there was a talk from Herb Sutter where he mentioned the plan was to migrate the kernel to compile with a C++ compiler. The idea of Core C++ Guidelines actually originated at Microsoft, before Bjarne and CERN guys got involved. Google doesn't allow native code on ChromeOS and on Android they make pretty clear that the NDK is just to make game developers happy and nothing else. They are all aware that C isn't going away tomorrow, but are driving efforts to make it as relevant in the future on their platforms as Assembly is today. When I started working in IT, the only OS written in C was UNIX. The language is not a sacred cow and the only thing preventing replacing it is the ubiquity of UNIX like OSes. OS not bound to the UNIX culture and POSIX compatibility are free to chose other language as their systems language. Not doing so, is usually a decision to cater to the status quo and ubiquity of existing developers and library (with their endless CVE entries).