Will there be performance and security improvements?

  • ExLisper@linux.community
    link
    fedilink
    English
    arrow-up
    58
    ·
    edit-2
    1 year ago

    It’s a better, more modern language in general. It has way better tooling (better, more user friendly compiler, better package manager), really good set of modern features (null-safety, good error handling, type-classes, algebraic types), it’s easier to modularize your code (workspaces, modules). Rust does a lot of things right and is fun to work with. That’s why it’s the most liked language overall. It’s not hype, it really is that good. It will just make working on the kernel easier. And on top of that it offers some memory safety and concurrency features.

    P.S. I forgot about amazing documentation. Again, way better then what you can find for C.

    P.P.S Zero cost abstractions.

    • duncesplayed@lemmy.one
      link
      fedilink
      English
      arrow-up
      39
      ·
      1 year ago

      The “tooling” argument is kind of backwards when we’re in the kernel. The package manager is not allowed to be used. Even the standard library is not allowed to be used. Writing code free of the standard library is kind of new in the Rust world and getting compiler support for it has been one of the major efforts to get Rust into the kernel. Needless to say tools around no-stdlib isn’t as robust as in the user world.

  • ProtonBadger@kbin.social
    link
    fedilink
    arrow-up
    56
    ·
    1 year ago

    I’ve been watching Asahi Lina develop a big GPU driver for Apple silicon and development was so much faster because a whole category of bugs were largely absent once the code compiled, and memory issues are notoriously difficult to fix. Also error handling is easier and much cleaner.

    She wrote about it here and here.

  • kopper [they/them]
    link
    fedilink
    English
    arrow-up
    50
    ·
    edit-2
    1 year ago

    Security? Probably. I wouldn’t expect any measurable improvements to performance but the with compiler being able to do more checks it might enable some clever optimization trickery that would be harder to maintain in C.

    Still, Rust on the kernel probably won’t leave the realm of drivers any time soon, so it all depends on if you have the hardware that will use a driver written in Rust.

    • Daybowbow@lemmy.world
      link
      fedilink
      English
      arrow-up
      31
      ·
      1 year ago

      Also to add: allowing Rust can bring in more developers to the kernel, given the growing popularity.

  • apt_install_coffee@lemmy.ml
    link
    fedilink
    arrow-up
    37
    ·
    edit-2
    1 year ago

    Memory safety is likely to prevent a lot of bugs. Not necessarily in the kernel proper, I honestly don’t see it being used widely there for a while.

    In third party drivers is where I see the largest benefit; there are plenty of manufacturers who will build a shitty driver for their device, say that it targets Linux 4.19, and then never support/update it. I have seen quite a few third party drivers for my work and I am not impressed; security flaws, memory leaks, disabling of sensible warnings. Having future drivers written in rust would force these companies to build a working driver that didn’t require months of trawling through to fix issues.

    Now that I think about it, in 10 years I’ll probably be complaining about massive unsafe blocks everywhere…

    • ozymandias117@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      ·
      1 year ago

      Haha. At least you immediately caught exactly what they’ll end up doing if they bother to use Rust at all 😂

  • Killercat103@infosec.pub
    link
    fedilink
    arrow-up
    34
    ·
    1 year ago

    Performance? Not really no. I believe C is slightly faster with Rust and C++ competing for second place. The benefit is safer code as Rust is built with performance and safety in mind. It highlights what potential errors can be found where making human error way less common. Instead of potential null errors types are wrapped in an option enumerator which ensures you know there can be a lack of a value. Expections are also enumerators done similarly with a result object so you know which functions may fail. Instead of using memory and potentially forgetting to free it we have the ownership system.

    • Rikudou_Sage@lemmings.world
      link
      fedilink
      arrow-up
      12
      ·
      1 year ago

      How is C faster than C++? Unless you use virtual functions, it’s as performant as C. And you definitely wouldn’t use virtual functions in a kernel.

      • Anti-Antidote@lemmy.zip
        link
        fedilink
        arrow-up
        30
        ·
        1 year ago

        C++ is only as fast as C if you use only the parts of C++ that are identical to C. In other words, C is faster than C++

          • PuppyOSAndCoffee@lemmy.ml
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            Compile time has got to be part of the convo esp when it comes to the kernel. The Linux kernel is one of the few bits where end-users are actively encouraged to compile from source. It is a feature!

            Adding C++ compilitis is pain for what gain, from a kernel pov.

            I am not a big fan of c++ overall however that is because other languages have emerged that are sweeter than C that gate some of the people issues with C++.

            Anyone who has ever had a thing that was like a thing but not exactly the thing, in C, knows C ain’t great at that.

            • cmeerw@programming.dev
              link
              fedilink
              arrow-up
              7
              ·
              1 year ago

              The description says:

              In this video, we’ll do a deep dive on what C++ Polymorphism is, what “virtual” does under the hood, and ultimately why it is SUCH a performance hit compared to languages like C and Rust.

              This is not about compile-time polymorphism.

          • Cpo@lemm.ee
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            Aside from that I think C is more performant than C++ (indeed when you use the bells and whistles that C++ offers), you are comparing the libraries with each other.

            The fact that the implementation of one random std::Sort is faster than the implementation of qsort() is comparing libraries, not the languages. You are comparing the algorithm of the Rust Sort with quicksort (which is obviously the qsort you are referring to.

            I am certain there are sort implementations in C which outperform Rust.

            Having said that, I immensely enjoy Rust because it forces me to think about the error handling and it does not give me the quirks of C/C++ (index out of bounds, memory corruption).

              • Cpo@lemm.ee
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                while C has to fiddle with void* and function pointer to get similar flexibility, which are much harder to optimize, as none of the type information is there.

                I thought we were discussing speed, not ease of use?

      • Zatujit@reddthat.com
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Since C++ has Turing complete compiling, I guess technically it can go infinite compilation time

  • dinosaurdynasty@lemmy.world
    link
    fedilink
    English
    arrow-up
    11
    ·
    1 year ago

    Potentially stability improvements as well (for the same reasons as the security improvements), especially for lesser used drivers and stuff.

  • YaBoyMax@programming.dev
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    1 year ago

    Yes, enhanced security is pretty much the entire pitch of Rust. There wouldn’t be any reason for it to result in performance enhancements, though.

      • ProtonBadger@kbin.social
        link
        fedilink
        arrow-up
        7
        ·
        edit-2
        1 year ago

        Well, it largely removes an attack surface for memory bugs, which is a huge thing. If we’re writing a big driver (see the Rust driver for the Apple GPU) then suddenly waving hands incoherently 90% or more of the driver (depending) is likely to be much more memory safe and stable. As has been demonstrated with that particular driver already.

        I was watching the streams and when it compiled Asahi Lina usually only had to deal with logical type errors, not memory issues, it was basically a great showcase for Rust and memory safely. Unsafe is perfectly fine Rust, but it’s a contract where the developer says to the compiler: “I know you can’t guarantee this block is safe, so I’ll keep a special eye on that, peer review more, test, etc. while you keep an eye on all the other code I can’t fit in my head”. In the case of Linux an Unsafe blocks means “we’ll trust the Linux kernel code we connect to, though review it carefully”.

        So saying all safety goes out the window is wrong, see it as a vastly reduced potential for memory problems, better error handling and more stable drivers, as demonstrated by the Apple GPU driver.

      • staticlifetime@kbin.social
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        It just depends on how isolated that part of the kernel is. Unsafe code should be done only in interop, and so it still theoretically has a memory safety benefit over C in that sense.

        In terms of how much interop code needs to be written for Rust at this point is another discussion though.

  • PuppyOSAndCoffee@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    I would choose zig over rust; while zig isn’t as safe as rust (nor is that zig’s aim) zig also is also safer than C. Zig still has a bit to go.

    Also rust compile times … in the kernel … that might matter more?

      • PuppyOSAndCoffee@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        multi-arch compile that is getting faster by the release, sweeter & safer than C — it isn’t unsafe, mind you — why wouldn’t you pick zig for systems development? And it’s compiled bins sizzle!

        Plus, there is no C interop; C just plugs in.

        The grammar is still in the oven, but once it bakes, I predict zig takes over C as a perf layer in script pkgs (python, node, etc).

        Compile times are crisp but some foundational elements (incremental compile etc) will help it positively fly. Already it’s smoking rust however we expect more.

        The grammar is why it is one to watch.

            • JulianRR@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              1 year ago

              I think at some level you can’t really get both. The rust compiler is constantly being sped up, but the amount of checking it does simply takes time.

              It’s the age old adage “The fastest code is the one that doesn’t exist”. The fastest compilation checks are the ones you don’t do.

              • PuppyOSAndCoffee@lemmy.ml
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                Situation is everything.

                speed matters when it comes to systems-level logic/code. Zig strikes that balance very nicely.

                Industry cares at the systems level. If a “safe” kernel is 4x slower (compilation, run-time) and there is an “unsafe” option that is just as secure, outside of a cadre of philosopher kings/queens (more power to 'em), practical teams will hit that unsafe performance boosting switch every time.

                C is as safe as the situation & the code dictates. Zig makes it easier to be safe in most situations and excels at promoting systems-level safety.

                App level, or app API? Where there is more of an x-factor? rust has a great use case. In “user-land”, availability matters almost as much as performance.. An app that always crashes is not as valuable as a slower app that never crashes…