Announcement

Collapse
No announcement yet.

Linux Developers Continue Evaluating The Path To Adding Rust Code To The Kernel

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

  • #31
    Originally posted by Alexmitter View Post
    As long as there is no way to compile rust with the by-far-better gcc
    Better by what metric? Rust with LLVM creates binaries that are as fast as C with GCC (for equivalent comparisons). In some cases Rust beats C and this will get better when LLVM improves its anti aliasing rules

    Originally posted by Alexmitter View Post
    and as long as it relies on cargo, keep that stuff out of the kernel.
    Rust doesn't rely on cargo (or cargo can be adapted for the Kernel needs) however its very painful to use Rust without cargo for the same reasons its painful with C, i.e. rolling your own dependency management.

    Comment


    • #32
      I just wonder does this introduce a whole new category of problems, where a kernel C-programmer misunderstood something the Rust part is doing?

      Comment


      • #33
        Originally posted by pmorph View Post
        I just wonder does this introduce a whole new category of problems, where a kernel C-programmer misunderstood something the Rust part is doing?
        That is actually a good point and a real potential problem. I think in practice it shouldn't be too bad if the use of Rust is (at least initially) confined to leaf code like drivers, where it's up to the Rust code to fit with the assumptions made in C. It's easier in that direction and at any rate, it will surely be a while before all the potential problems are ironed out.

        Comment


        • #34
          I wonder how they would handle the quick release cycle of Rust. There's no Rust LTS...

          Comment


          • #35
            Originally posted by ernstp View Post
            I wonder how they would handle the quick release cycle of Rust. There's no Rust LTS...
            No reason why that can't change, should the need arise.
            There's no point bothering with LTS in the first iterations (of anything). But by now I think Rust is mature enough. Since it got async/await, there's no prominent feature I can think of that is still missing. I'm sure there are some, but, more importantly, there's no slew of big incoming changes anymore.
            I'm also not sure there will be a need for LTS. Since the compiler already guarantees the code will work a certain way, you won't be as pressed to keep it at a certain version so it won't break this and that. Of course, it's still written by humans, so who knows?

            Comment


            • #36
              Originally posted by Alexmitter View Post
              As long as it relies on cargo
              You can invoke `rustc` directly. It is trivial for a single-file hello-world program. Try it! But with modules and multiple source files, I suspect it gets complicated, so I haven't ventured there.

              Oh, and Meson supports Rust now, if you need a polyglot buildsystem.
              Last edited by andreano; 28 August 2020, 12:02 PM.

              Comment


              • #37
                Originally posted by mdedetrich View Post
                its painful with C, i.e. rolling your own dependency management.
                Compared to Rust it seems that C or C++ barely needs dependency management.

                For example if we need access to SDL from C, we install it (or at the very most install the *-dev) packages.

                With Rust, you need to do that *plus* drag in a libc compat binding, which of course drags in std-workspace-core, before you can even think about using SDL. Next up are the num and rand dependencies needed by the SDL bindings (for some stupid reason rust doesn't have such things in a std library?), num has ~7 extra dependencies (not counting recursive deps), rand has rand-core, rand-hc, rand-chacha. This of course depends on ppv-lite86. I counted about 20 extra dependencies just to use a C API before I stopped and just used C++ instead.

                Did I roll my own dependency management? No, I just listed on the README that SDL2 is required. I know for a fact users will find this easier than faffing with bitrotted cargo dependencies in ~10 years. Cargo is just sloppy JavaScript styled crap from an obviously web development-centric company. It needs to be better for quality systems programming.
                Last edited by kpedersen; 28 August 2020, 12:49 PM.

                Comment


                • #38
                  Originally posted by kpedersen View Post

                  Compared to Rust it seems that C or C++ barely needs dependency management.
                  That's not really my experience. More often than not C or C++ projects don't list clearly what they need. It's good if you can list them properly in your own projects. Sometimes when they do list their dependencies, that still doesn't tell you what you need to actually install. Okay, if it's just SDL, that's easy enough to find it in the package manager but generally you need to know more. Sometimes the library is not actually packaged with the name you expected. Now that I know the tools I can usually find what's needed but for a rookie it's even more work and doesn't really encourage anyone to build their own software (usually a prerequisite to contribute any code, and you have to start somewhere). When there starts to be more than 10 libraries needed, it's actually quite a bit of manual work to install all of them. It's quite a bit more threshold to start contributing when comparing this to having cargo to download those dependencies with one command.

                  Also in C and C++ world some projects use pkgconf to manage dependencies. That's already a big improvement to finding and then installing them manually. That's not unlike using cargo but instead of a centralized repository they are depenedent on different package managers and distributions' packagers to package them. Hard to say which one is better as both have their upsides and downsides.

                  Comment


                  • #39
                    Originally posted by Tomin View Post
                    When there starts to be more than 10 libraries needed, it's actually quite a bit of manual work to install all of them.
                    I do get that. When you have a C++ project with 10+ dependencies it means it is a fairly large project. However the way Rust / Cargo works is that you end up needing around 10 dependencies for a fairly trivial Hello World program. Yes I exaggerate a little but it is still a fair problem.

                    I guess dependency managers like Cargo end up encouraging developers to drag in fairly unnecessary dependencies. At the same time Rust needs a dependency manager because it needs bindings for 99.9% of the C libraries. My solution would be to add a tiny C compiler to Rust which could eliminate the need for a dependency manager and ultimately reduce the total number of dependencies.

                    Comment


                    • #40
                      Originally posted by kpedersen View Post

                      I do get that. When you have a C++ project with 10+ dependencies it means it is a fairly large project. However the way Rust / Cargo works is that you end up needing around 10 dependencies for a fairly trivial Hello World program. Yes I exaggerate a little but it is still a fair problem.

                      I guess dependency managers like Cargo end up encouraging developers to drag in fairly unnecessary dependencies. At the same time Rust needs a dependency manager because it needs bindings for 99.9% of the C libraries. My solution would be to add a tiny C compiler to Rust which could eliminate the need for a dependency manager and ultimately reduce the total number of dependencies.
                      While what you say is true, I would add that once a language ecosystem adopts a dominant dependency management tool, then people start using orders of magnitude more dependencies. I have seen that happen in Java when ot transitioned sometime in the 00's to the maven system and JavaScript as well in the latest years where now every js project, hobby or not, downloads hundreds on interdependent libraries.

                      In C/C+ however that has not happened. Even though there have been attempts and projects on this front, there has not been any dominant one. They also carry a larger cultural heritage that makes it difficult to change how things have worked.

                      Comment

                      Working...
                      X