Announcement

Collapse
No announcement yet.

Rust For Linux Kernel v9 Patches Trim Things Down Greatly For Easier Upstreaming

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

  • #11
    Originally posted by kpedersen View Post
    I don't think anyone truly thought that a full fat Rust support was ever going to enter the kernel (and certainly not standard library, cargo, crates.io)

    Possibly why C++ struggled in Linux kernel space is because after stripping it down to the core useful parts, you are more or less back at C again. Rust will likely be no different.
    Thats the biggest load of bs i ever heard. C++ without STL is nothing like C whatsoever.

    i think what others said hits the mark better its to keep google facebook or whatever happy. Money is the root of evil.

    Comment


    • #12
      I also got the impression that Linus was not a fan of a language which has "userland-first" design features like transparently adding a vtable member in your struct or class if you want to use the language's syntactic sugar for dynamic dispatch and a tendency to encourage people to think in failure-by-exception.

      Comment


      • #13
        Originally posted by cj.wijtmans View Post

        Thats the biggest load of bs i ever heard. C++ without STL is nothing like C whatsoever.

        i think what others said hits the mark better its to keep google facebook or whatever happy. Money is the root of evil.
        It is not just STL, it is std too and stuff like boost because they are most of time not made in mind that allocation of memory in kernel is done using diffrent functions.

        When you strip C++ and Rust out of standard libraries, C++ offers some features that are not sufficient enough to add entire new language.

        Rust actually does offer some features that are hard to pass by like memory safety, good multithreading. This is primary reason why companies (and Linus too) are accepting Rust or embracing it - because removing risk from software is something you should do.

        Also that is not all, for example Rust async is quite stable and doesn't require any imports and async boilerplate for kernel already does exist to use it right.

        in C++ you have to make imports for that, that are likely to not work in kernel. If they don't work in kernel that means you need to implement entire coroutines by yourself which means you reinvent the wheel what could be done in C as well somehow. And even if coroutines import somehow would work its support by compilers is wacky.
        Last edited by piotrj3; 05 August 2022, 07:59 PM.

        Comment


        • #14
          It is astounding how many people in the comments here have no idea what's going on.

          This stripped down patch series isn't supposed to be the final word. In fact, I'm surprised it's even possible to compile a kernel module with it. The point of separating things out like this is simply to make a smaller patch series that's easier for reviewers to read over the next week. Then they'll probably come back with another chunk of the full patch series each kernel cycle until the whole thing is merged. That's how RT has finally made it into the mainline after all. Not in one big gulp but instead as a series of incremental parts.

          As for C++, someone was right to point out that C++ doesn't offer much when you strip it down. Fundamentally, there are no advantages to the kernel over C, other than a bunch of ways to make prefabbed bullshit. Rust code on the other hand, even when so feature-deprived as to be nearly useless, is still provably safe. The language contains no undefined behavior. Once the basic cruft for building rust code is merged, it's merely a matter of adding back in bindings for each kernel subsystem and whatnot so that people can implement the crap they actually want to use it for.

          Comment


          • #15
            Originally posted by piotrj3 View Post
            Also that is not all, for example Rust async is quite stable and doesn't require any imports and async boilerplate for kernel already does exist to use it right.

            in C++ you have to make imports for that, that are likely to not work in kernel.
            Just implement a C++ library for the Linux with async and threading. It doesn't matter whether functionality is built-in in the language or exists as a library - someone need to implement it anyways.

            Comment


            • #16
              Originally posted by Developer12 View Post
              As for C++, someone was right to point out that C++ doesn't offer much when you strip it down. Fundamentally, there are no advantages to the kernel over C, other than a bunch of ways to make prefabbed bullshit.
              I bet you don't have much experience with C++. It's way more better and safer than C while maintain the same low level features and zero cost abstractions.

              Comment


              • #17
                Originally posted by kpedersen View Post

                Indeed. Rust would have failed very hard back then. But now Linus has commercial companies to keep happy.
                Rust didn't exist back then. Today Linus has his users to keep happy just like back then, and just like back then, he's being pragmatic, not ideological. On a side note, of course he must make commercial companies happy. And I'm very happy that it's the case. I want FOSS to be used for real production use cases.

                Comment


                • #18
                  Originally posted by Developer12 View Post
                  It is astounding how many people in the comments here have no idea what's going on.
                  It's the Denning-Krueger Effect in action.

                  Comment


                  • #19
                    Originally posted by cj.wijtmans View Post

                    Thats the biggest load of bs i ever heard. C++ without STL is nothing like C whatsoever.
                    I said "core useful parts". Gonna have to strip a lot more out than just STL

                    In kernel land, that will mean stripping exceptions, RTTI. Probably also excluding the use of references and RAII. Its usage will end up even being closer to C99, than K&R C is to C99.

                    Comment


                    • #20
                      Originally posted by kpedersen View Post

                      I said "core useful parts". Gonna have to strip a lot more out than just STL

                      In kernel land, that will mean stripping exceptions, RTTI. Probably also excluding the use of references and RAII. Its usage will end up even being closer to C99, than K&R C is to C99.
                      Why excludes references and RAII?
                      These two features does not obfuscate the logic like exceptions and are both zero-cost abstraction.

                      Comment

                      Working...
                      X