6 ms·

It's also a problem for application themselves IMO. Cargo combined with dependency pinning brings most of the disadvantages of similar environments with central

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
      Is there any sort of detailed documentation on how to use rustc directly in more complex ways? I imagine that any begginer's text will mostly treat cargo and not such special usage scenarios as this one.
- gspr 5y ago
  True in principle. But once you divorce yourself from Cargo, almost all resources and advice when it comes to building Rust programs go out the window. I love the language, and I love the community, but the attitude of "rustup nightly and Cargo, or bust" is bit terrifying. As a noob, I had to wade through endless "but don't do that, just get the latest from Cargo!!!!" when I asked for advice on how to use my system-provided Rust packages for my project.
  - nerdponx 5y ago
    For what it's worth, system-provided can be arbitrary and vary widely between systems. Moreover, in the Python world a distinction is made between "software that runs your system" and "software that you use for development"; maybe Rust people think similarly.
    - gspr 5y ago
      > For what it's worth, system-provided can be arbitrary and vary widely between systems. Sure. That's inherent with software. > Moreover, in the Python world a distinction is made between "software that runs your system" and "software that you use for development"; maybe Rust people think similarly. What?

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
    Is there any sort of detailed documentation on how to use rustc directly in more complex ways? I imagine that any begginer's text will mostly treat cargo and not such special usage scenarios as this one.
gspr 5y ago
True in principle. But once you divorce yourself from Cargo, almost all resources and advice when it comes to building Rust programs go out the window. I love the language, and I love the community, but the attitude of "rustup nightly and Cargo, or bust" is bit terrifying. As a noob, I had to wade through endless "but don't do that, just get the latest from Cargo!!!!" when I asked for advice on how to use my system-provided Rust packages for my project.
- nerdponx 5y ago
  For what it's worth, system-provided can be arbitrary and vary widely between systems. Moreover, in the Python world a distinction is made between "software that runs your system" and "software that you use for development"; maybe Rust people think similarly.
  - gspr 5y ago
    > For what it's worth, system-provided can be arbitrary and vary widely between systems. Sure. That's inherent with software. > Moreover, in the Python world a distinction is made between "software that runs your system" and "software that you use for development"; maybe Rust people think similarly. What?