Announcement

Collapse
No announcement yet.

Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Ok, but how is the code written in Rust compared to C at the performance level ?
    Is Rust adding any safety checks at runtime that makes the code slower based on the assumption that the code is badly written ?

    Comment


    • #12
      Originally posted by pal666 View Post
      and nothing works, that's why nothing but c++ is used as viable replacement for c
      i didn't say "call c code", i said "understand c headers". even perl can "call c code"
      A quick Google lookup will teach you that Rust bindgen *understands C headers* and generates Rust bindings from that.

      Comment


      • #13
        Originally posted by Danny3 View Post
        Ok, but how is the code written in Rust compared to C at the performance level ?
        Is Rust adding any safety checks at runtime that makes the code slower based on the assumption that the code is badly written ?
        Rust's safety checks are statically analyzed. Compilation time is a bit slower, but there aren't runtime checks. Features involving dynamic casting are always expensive, whether written manually or supported by language.

        Comment


        • #14
          Originally posted by pal666 View Post
          well, it has to be disabled by default because gcc 4.9 doesn't support it
          I don't see why that's an issue. Once some non optional part of Linux gets written in Rust, you'll need a rust compiler to build it. That required compiler might not be under the GNU Compiler Collection umbrella.

          Comment


          • #15
            Originally posted by p91paul View Post

            A quick Google lookup will teach you that Rust bindgen *understands C headers* and generates Rust bindings from that.
            It generates "a good start" but for anything remotely complex you need to spend a large amount of man hours to solve.

            Things like:
            • C-style callbacks
            • Opaque pointers
            • Type-casting to first internal struct (poor man's oop)
            • Non-owning arrays
            • Multi-threading
            All while, what you get out is completely 100% "unsafe". So you then need the "fat binding" on top which takes even more man hours before you can start to get the benefits.

            I don't actually mind rust in the kernel. I am a bit weary of bindings becoming unmaintained and in the way. I honestly think the reason why other languages haven't managed to beat C/C++ in multiple domains is because they don't include the ability to consume C headers. I strongly believe that Objective-C will ultimately outlive Swift for this same reason.

            If we can all migrate to Rust as the "defacto native systems language", I will be very pleased! I just think binding generators is the wrong approach and just breeds language package managers like Crates.io, NPM, PIP, CPAN which simply rack up technical debt with dependencies and screw project lifespans and deterministic development.
            Last edited by kpedersen; 07-11-2020, 12:26 PM.

            Comment


            • #16
              First the inclusive bullshit, now this?

              Linux is really doomed, I guess.

              Comment


              • #17
                All part of the effort to get the kernel to run as fast and as well as firefox

                Maybe mozilla should be in charge of developing the kernel going forward.

                Comment


                • #18
                  Originally posted by Weasel View Post
                  Linux is really doomed, I guess.
                  No, Weasel is.

                  Comment


                  • #19
                    Originally posted by kpedersen View Post

                    It generates "a good start" but for anything remotely complex you need to spend a large amount of man hours to solve.

                    Things like:
                    • C-style callbacks
                    • Opaque pointers
                    • Type-casting to first internal struct (poor man's oop)
                    • Non-owning arrays
                    • Multi-threading
                    All while, what you get out is completely 100% "unsafe". So you then need the "fat binding" on top which takes even more man hours before you can start to get the benefits.
                    It all depends on how you do it. Non-owning arrays are easy. They are called slices in rust. Typically represented via a pointer and a length in a FFI.

                    Also, there is nothing wrong in calling functions marked unsafe in your driver. You just have to check the functions requirements yourself.

                    Considering the rest you listed, I suggest you have a look at what GTK did with its rust bindings. They did lots of experimentation how to wrap C stuff idiomatically, but they turned out pretty nice, IMHO. You can even run rust futures (or async functions for that matter) on a glib based executor.

                    EDIT:

                    Async functions also work nicely with interrupts. The interrupts can wake some async task when it has new data. The following (from the Writing an operating system in rust blog series) is a good read. They show how to implement a keyboard driver:

                    https://os.phil-opp.com/async-await/
                    Last edited by oleid; 07-11-2020, 01:29 PM.

                    Comment


                    • #20
                      It is all a conspiracy. The world is coming to an end! We are getting opressed.

                      Seriously, Rust looks like the biggest innovation in _systems_ languages in years, and Linus not having a fit about it speaks volumes...

                      Comment

                      Working...
                      X