6 ms·

The latter point is an important one. Rust as a language for libraries cannot work the same way as rust as a language for applications. For the latter it is OK

The latter point is an important one. Rust as a language for libraries cannot work the same way as rust as a language for applications. For the latter it is OK to depend on the cargo toolchain and be opinionated when it comes to things like dynamic linking. For the former you ideally want support in any common compiler (clang, GCC) and as little dependencies and constraints as possible.

bsdubernerd 5y ago
It's also a problem for application themselves IMO. Cargo combined with dependency pinning brings most of the disadvantages of similar environments with centralized package handling: the ease of adding package dependencies increases the number of dependencies themselves very rapidly. Overly-narrow version pinning forces per-package lockstep updates of the various dependencies, which in turn means multiple versions of the same package will get pulled two-or-three levels deep. This ensures each single rust package or update you build is almost a guaranteed rebuild-the-world even with a shared cache dir. And we're not touching the problem of building projects where rust is only part of it: annoying if you want to link other stuff into rust, even more so if you want to do the opposite. I'm following a couple of projects that transitioned to rust, and my experience as a contributor is not stellar. A minimal rust project can take hundreds of mb of disk space just in dependencies, and double that for build space. The solution for some has been providing build bots, but again doesn't help me as a contributor, where I need to be able to rebuild from source. This has on me almost the same effect produced by large projects: I only contribute if I have a large vested interest in the package, otherwise I just avoid because it's time consuming.
- kortex 5y ago
  Cargo != rust. They are different things for a reason. You don't ever need cargo to manage deps or build, it's just idiomatic to do so. Nothing stopping you from building rust code with manual vcs, rustc, autoconf, and make, just like C.
  - bsdubernerd 5y ago
    Yes, however they're much more tied together as an ecosystem than, say, python and pip.
    - steveklabnik 5y ago
      Notably for this thread, Linux will not be using Cargo.
      - kortex 5y ago
        Thanks for clearing that up. Say, you know a lot of things about the rust ecosystem. Do you have any insight into how hypothetical rust driver code would integrate with the rest of the kernel build process? I imagine it would have to use llvm-rustc, or is gccrs ready for the job? Would it be emitting objects that gcc/ld would link against?
        steveklabnik 5y ago
        > Do you have any insight Well, this is a working patch set, so, yes, though I have no direct involvement and haven't read all of it yet. > I imagine it would have to use llvm-rustc, Yes, it uses upstream rustc. > is gccrs ready for the job? Not yet. They're making great progress, but major chunks of the language are still missing. They'll get there. Using upstream rustc isn't a blocker for new code implementing drivers, but it is a blocker for getting into older drivers, or the kernel. The blocker is platform support; or at least, the current largest blocker, and either rustc will gain it, or gccrs will be good enough to compile this codebase. We'll see :) > Would it be emitting objects that gcc/ld would link against? Yep, it emits output that looks like any C compiler's output, you link 'em together and you're good. If you manage to compile the kernel with clang, in theory you can even get cross-language LTO; this is working in Firefox, but I'm not sure if anyone's tried it with the kernel yet or not.
        xvilka 5y ago
        > If you manage to compile the kernel with clang, in theory you can even get cross-language LTO. Note, that there is still bunch of unsolved issues [1] in LLVM to allow all building all of Linux kernel. The efforts had stopped for some years but recently gained steam again, though a lot of time was wasted before. [1] https://bugs.llvm.org/show_bug.cgi?id=4068 https://bugs.llvm.org/show_bug.cgi?id=4068
jhgb 5y ago
Even if you're compiling dynamic libraries/.so's with a C ABI to be consumed through a C FFI from another language? That seems to be fairly common use case these days, and I don't see those issues there (unless I've missed something, which is of course very possible).
- zozbot234 5y ago
  Rust itself largely supports this (via the 'cdynlib' project type), however for many Rust crates it either does not make sense to export a pure C API/ABI (i.e. the "crates" are purely generic code that's going to be instantiated with build-specific types, so there's no predefined API beyond that single build) or they just don't bother to enable that use case.
  - jhgb 5y ago
    Well, sure, language-level API (with a type system identical to Rust's) will be a problem, but as long as there's only one compiler, there doesn't seem to be a problem -- yet. I'm mildly wondering if this isn't a chicken and egg problem of sorts.

bsdubernerd 5y ago

It's also a problem for application themselves IMO. Cargo combined with dependency pinning brings most of the disadvantages of similar environments with centralized package handling: the ease of adding package dependencies increases the number of dependencies themselves very rapidly. Overly-narrow version pinning forces per-package lockstep updates of the various dependencies, which in turn means multiple versions of the same package will get pulled two-or-three levels deep. This ensures each single rust package or update you build is almost a guaranteed rebuild-the-world even with a shared cache dir. And we're not touching the problem of building projects where rust is only part of it: annoying if you want to link other stuff into rust, even more so if you want to do the opposite. I'm following a couple of projects that transitioned to rust, and my experience as a contributor is not stellar. A minimal rust project can take hundreds of mb of disk space just in dependencies, and double that for build space. The solution for some has been providing build bots, but again doesn't help me as a contributor, where I need to be able to rebuild from source. This has on me almost the same effect produced by large projects: I only contribute if I have a large vested interest in the package, otherwise I just avoid because it's time consuming.

kortex 5y ago
Cargo != rust. They are different things for a reason. You don't ever need cargo to manage deps or build, it's just idiomatic to do so. Nothing stopping you from building rust code with manual vcs, rustc, autoconf, and make, just like C.
- bsdubernerd 5y ago
  Yes, however they're much more tied together as an ecosystem than, say, python and pip.
  - steveklabnik 5y ago
    Notably for this thread, Linux will not be using Cargo.
    - kortex 5y ago
      Thanks for clearing that up. Say, you know a lot of things about the rust ecosystem. Do you have any insight into how hypothetical rust driver code would integrate with the rest of the kernel build process? I imagine it would have to use llvm-rustc, or is gccrs ready for the job? Would it be emitting objects that gcc/ld would link against?
      - steveklabnik 5y ago
        > Do you have any insight Well, this is a working patch set, so, yes, though I have no direct involvement and haven't read all of it yet. > I imagine it would have to use llvm-rustc, Yes, it uses upstream rustc. > is gccrs ready for the job? Not yet. They're making great progress, but major chunks of the language are still missing. They'll get there. Using upstream rustc isn't a blocker for new code implementing drivers, but it is a blocker for getting into older drivers, or the kernel. The blocker is platform support; or at least, the current largest blocker, and either rustc will gain it, or gccrs will be good enough to compile this codebase. We'll see :) > Would it be emitting objects that gcc/ld would link against? Yep, it emits output that looks like any C compiler's output, you link 'em together and you're good. If you manage to compile the kernel with clang, in theory you can even get cross-language LTO; this is working in Firefox, but I'm not sure if anyone's tried it with the kernel yet or not.
        xvilka 5y ago
        > If you manage to compile the kernel with clang, in theory you can even get cross-language LTO. Note, that there is still bunch of unsolved issues [1] in LLVM to allow all building all of Linux kernel. The efforts had stopped for some years but recently gained steam again, though a lot of time was wasted before. [1] https://bugs.llvm.org/show_bug.cgi?id=4068 https://bugs.llvm.org/show_bug.cgi?id=4068

jhgb 5y ago

Even if you're compiling dynamic libraries/.so's with a C ABI to be consumed through a C FFI from another language? That seems to be fairly common use case these days, and I don't see those issues there (unless I've missed something, which is of course very possible).

zozbot234 5y ago
Rust itself largely supports this (via the 'cdynlib' project type), however for many Rust crates it either does not make sense to export a pure C API/ABI (i.e. the "crates" are purely generic code that's going to be instantiated with build-specific types, so there's no predefined API beyond that single build) or they just don't bother to enable that use case.
- jhgb 5y ago
  Well, sure, language-level API (with a type system identical to Rust's) will be a problem, but as long as there's only one compiler, there doesn't seem to be a problem -- yet. I'm mildly wondering if this isn't a chicken and egg problem of sorts.