4 ms·

This is the one place where Rust differs from many other languages: Dependencies and libraries are typically brought in a source-dependencies and built with you

This is the one place where Rust differs from many other languages: Dependencies and libraries are typically brought in a source-dependencies and built with your own code. This typically makes the first build of any project considerably slower than for other languages, since you have to also build all your dependencies, but I think it allows for a really simple and predictable way to work, not to mention support any kind of architecture, across all packages. It's obviously a trade-off, but I think it's a trade-off which is clearly worth it.

pjmlp 7y ago
A trade off that requires buying a compiler rig, it is almost unusable to compile Rust stuff from scratch on my travel netbook. If I plan to do some Rust coding on the go (no pun intended), better do a full build at home before packing. A 5m C++ build turns into 30m Rust one, for the same project, ported across languages. Not to mention that it means on a large team project everyone one is compiling the same stuff over and over again, given that cargo does not yet support code cache servers. Yes there are some workarounds like sccache, but they are extra stuff one needs to install.
- josteink 7y ago
  > Not to mention that it means on a large team project everyone one is compiling the same stuff over and over again, That's a bit dramatical. You typically only compile your dependencies once during the project lifetime. If you on your netbook have done a initial full build, you'll only get incremental builds from there on, just like with C++. But unlike C++, dependency management isn't hell, and you are almost always guaranteed to have your dependency supported on the target you are building, OOB, without any fiddling or setup. It's a trade-off, but I definitely think the Rust-team made the right decision here.
  - pjmlp 7y ago
    Dependency management isn't an issue when using OS packages, and Conan also does binary dependencies. Compiling from source also does not solve the problem that a crate author hasn't taken a specific OS into account. Yes I am being a bit dramatic, but this kind of issues do impact adoption, and there are many industries where shipping source is just not an option.
    - josteink 7y ago
      > Dependency management isn't an issue when using OS packages Come on. What do you find most developer friendly? 1. "cargo build && done" or 2. Try to uncover what dependencies this project really has, and then proceed to map out what the packages (and dev-packages) for those dependencies are called on the linux distro you are using (debian, ubuntu, fedora, arch, etc), not to mention what they are called on your specific version of that distro, root up, install all that stuff.... and then try ./configure yet again? > but this kind of issues do impact adoption Indeed. In 2020 I wouldn't bother adopting any kind of language which prefers the latter flow to the former one.
      - pjmlp 7y ago
        "cargo build && done" only works if every crate author has taken my OS into consideration and not used OS specific API or file locations. And it is more like "cargo build && off to lunch". I am usually on Windows, and most commercial vendors nicely sell us their already compiled binaries. No need to hunt for anything. Regarding Linux distros, if it isn't on the official repositories, Conan provides exactly the same experience as cargo, only faster because it supports binary libraries.
        josteink 7y ago
        And how many C/C++ projects use Conan by default, versus those who don't? For comparison all rust projects uses cargo. The ergonomic value of that is something you simply can not overstate.
        pjmlp 7y ago
        For many users of AOT compiled languages, the ergonomic factor is being able to enjoy fast builds, without getting a compiler rig. Turbo Pascal 7, which was already relatively complex, was already compiling several thousand lines per minute on a single core 4Mhz computer bounded to 640KB. More modern examples with complexer type systems, are languages like Delphi, FreePascal, Ada/SPARK, D, F# via .NET AOT, OCaml. So yeah cargo is nice, but not if I have to build everything from scratch, Rust isn't a scripting language.

pjmlp 7y ago

A trade off that requires buying a compiler rig, it is almost unusable to compile Rust stuff from scratch on my travel netbook. If I plan to do some Rust coding on the go (no pun intended), better do a full build at home before packing. A 5m C++ build turns into 30m Rust one, for the same project, ported across languages. Not to mention that it means on a large team project everyone one is compiling the same stuff over and over again, given that cargo does not yet support code cache servers. Yes there are some workarounds like sccache, but they are extra stuff one needs to install.

josteink 7y ago
> Not to mention that it means on a large team project everyone one is compiling the same stuff over and over again, That's a bit dramatical. You typically only compile your dependencies once during the project lifetime. If you on your netbook have done a initial full build, you'll only get incremental builds from there on, just like with C++. But unlike C++, dependency management isn't hell, and you are almost always guaranteed to have your dependency supported on the target you are building, OOB, without any fiddling or setup. It's a trade-off, but I definitely think the Rust-team made the right decision here.
- pjmlp 7y ago
  Dependency management isn't an issue when using OS packages, and Conan also does binary dependencies. Compiling from source also does not solve the problem that a crate author hasn't taken a specific OS into account. Yes I am being a bit dramatic, but this kind of issues do impact adoption, and there are many industries where shipping source is just not an option.
  - josteink 7y ago
    > Dependency management isn't an issue when using OS packages Come on. What do you find most developer friendly? 1. "cargo build && done" or 2. Try to uncover what dependencies this project really has, and then proceed to map out what the packages (and dev-packages) for those dependencies are called on the linux distro you are using (debian, ubuntu, fedora, arch, etc), not to mention what they are called on your specific version of that distro, root up, install all that stuff.... and then try ./configure yet again? > but this kind of issues do impact adoption Indeed. In 2020 I wouldn't bother adopting any kind of language which prefers the latter flow to the former one.
    - pjmlp 7y ago
      "cargo build && done" only works if every crate author has taken my OS into consideration and not used OS specific API or file locations. And it is more like "cargo build && off to lunch". I am usually on Windows, and most commercial vendors nicely sell us their already compiled binaries. No need to hunt for anything. Regarding Linux distros, if it isn't on the official repositories, Conan provides exactly the same experience as cargo, only faster because it supports binary libraries.
      - josteink 7y ago
        And how many C/C++ projects use Conan by default, versus those who don't? For comparison all rust projects uses cargo. The ergonomic value of that is something you simply can not overstate.
        pjmlp 7y ago
        For many users of AOT compiled languages, the ergonomic factor is being able to enjoy fast builds, without getting a compiler rig. Turbo Pascal 7, which was already relatively complex, was already compiling several thousand lines per minute on a single core 4Mhz computer bounded to 640KB. More modern examples with complexer type systems, are languages like Delphi, FreePascal, Ada/SPARK, D, F# via .NET AOT, OCaml. So yeah cargo is nice, but not if I have to build everything from scratch, Rust isn't a scripting language.