I mean, that’s not a Rust issue per se. It’s only noticeable because cargo is much better than most build systems, and hence is an actual option for distribution of software. But there should ideally always be a binary distribution. I know some people like to build everything by themselves, but I get it, it’s annoying.
Okay so, this is less a line in the sand and more a 14 foot concrete wall topped with razor wire and guarded by marines with rifles with fixed bayonets in the sand:
I will not install an end-user application using Cargo, and I will say many mean things to anyone who suggests it.
Python’s Pip or Pypi or PyPy whichever it is (Both of those are the names of two different things and no one had their head slammed into a wall for doing that; proof that justice is a fictional concept) I can almost accept. You could almost get me drunk enough to accept distributing software via Python tooling, because Python is an interpreted language, whether you ship me your project as a .exe, a .deb, a flatpak, whatever, you’re shipping me the source code. Also, Python is a pretty standard inclusion on Linux distros, so Pip is likely to be present.
Few if any distros ship with Rust’s toolset installed, and the officially recommended way to install it, this is from rust-lang.org…is to pipe curl into sh. Don’t ask end users to install a programming language to compile your software.
Go ahead and ask your fellow developers to compile your software; that’s how contributing and forking and all that open source goodness should be done. But not end users. Not for “Install and use as intended.” For that, distribute a compiled binary somehow; at the very least a dockerfile if a service or an appimage if an application. Don’t make people who don’t develop in Rust install the Rust compiler.
For people who do this, is the purpose to ensure you are not getting a bad binary which has some malicious code compiled in?
If yes, isn’t it more difficult to check all the source code yourself? You may as well trust a binary where the author has confirmed a hash of the binary. Unless you really are checking every single line of source code. But then I wonder how you get anything else done.
The incident from xz gives a good example of where self-compiling stuff would be a good idea.
The code was mostly fine, but the maintainer managed to include malicious instructions in the binary. Most people who read the source, didn’t realise the possibility. I checked it out afterwards and it was still hard to get.
The idea is that someone is checking the code. And by building it yourself, you can at least ensure that you’re getting what’s built from the code. It is possible that some malicious stuff was inserted while building the binary that doesn’t show up in the source code. Building from source solves that problem.
Reproducible builds try to solve that problem by generating some provenance from a third party. A middle ground can be building the binary using something like GitHub Actions, since that can be audited by others. That comes with its own can of worms since GH is owned by M$, but I digress.
So it is technically sane to do it, just not very practical in my view. But for lesser known apps, I do sometimes build from source.
Yeah, the good tooling also means it isn’t even terribly difficult for the dev to provide builds, but it isn’t quite as automated as publishing to crates.io, so many don’t bother with automating or manually uploading…
Pypi isn’t in any way less an option for distributing software countless projects that use it that way can be used as a proof. Hell, awscli installed from pypi for ages. In my experience cargo is extremely slow at downloading hundred libraries that every program needs and rustc is extremely slowly builds them.
Correction, uv isn’t in any way less an option. pypi is only the registry. If you are using pip you will end up in dependency hell, you might use something like poetry to avoid that, but uv is just better.
But… wait a minute… uv is inspired by cargo, and it’s also written in rust. That’s quite the coincidence, huh?
Also, cargo is fast, it’s rustc that’s slow, and that’s because rustc is doing advanced code analysis. Compiling rust is actually NP-hard, but in exchange for that, the compiler will catch bugs in place of the developer. Which is a good tradeoff considering that you only compile once and run many times.
“countless projects that use it that way” isn’t proof of anything. Countless projects tell you to curl a 2000 lines script into sudo bash that will fill your os with bullshit.
Pip is a sane default that works for absolute majority of cases, anyway correct tool for installing programs from pypi is pipx that eliminates ‘dependency hell’, but ofc new cool tool is the only way to do things.
When little program in rust that replaced previous one compiles two hours compared to previous that compiled in a few minutes it matters.
UV is a lot more than pipx. It installs applications from pypi, without dependency hell, but it also uses hard links when possible to avoid wasting space. But it’s also a dev tool. It manages python installations, workspaces, you can use it to edit the pyproject, it can also publish to pypi, even from a GitHub action if set up from pypi. It just does a lot more.
I know what uv is, also never felt the need for package manager do a lot more. Just not my use case, pip + pipx is enough for me. I do develop in python but I’m trying to do it as tidy as possible without any or minimal external deps due to environment constraints, maybe for web dev or other fields where there is a need to install billion external libraries and multiple versions of them uv is a right choice, who knows. Personally I would prefer first party tool.
None of the issues you’ve described are Cargo’s fault. The long compilation time is simply rustc’s compile-time checks (ensuring type and memory safety is much more involved than lexing in GCC), and the number of dependencies to compile is a result of the crate ecosystem. Cargo is just the front-end that automates fetching dependencies and compilation with rustc. Blaming it for slow compilation is like hitting your monitor when the computer is acting up.
I’m not blaming cargo specifically for building it is slow to download deps as well, which was clearly stated in my first post. I’m going to edit it now.
The Rust compiler is more sophisticated than most compilers, so it can be slower at the same kind of tasks. But it also just does a different task here.
One of the tradeoffs in Rust’s design is that libraries get compiled specifically for a concrete application. So, whereas in most programming languages, you just download pre-compiled libraries, in Rust, you actually download their source code and compile all of it on your machine.
This isn’t relevant, if you get a pre-built binary. And it’s not particularly relevant during development either, because you get incremental compilation. But yeah, if someone wants to compile a Rust codebase from scratch, then they have to sit through a long build.
I mean, that’s not a Rust issue per se. It’s only noticeable because
cargois much better than most build systems, and hence is an actual option for distribution of software. But there should ideally always be a binary distribution. I know some people like to build everything by themselves, but I get it, it’s annoying.Okay so, this is less a line in the sand and more a 14 foot concrete wall topped with razor wire and guarded by marines with rifles with fixed bayonets in the sand:
I will not install an end-user application using Cargo, and I will say many mean things to anyone who suggests it.
Python’s Pip or Pypi or PyPy whichever it is (Both of those are the names of two different things and no one had their head slammed into a wall for doing that; proof that justice is a fictional concept) I can almost accept. You could almost get me drunk enough to accept distributing software via Python tooling, because Python is an interpreted language, whether you ship me your project as a .exe, a .deb, a flatpak, whatever, you’re shipping me the source code. Also, Python is a pretty standard inclusion on Linux distros, so Pip is likely to be present.
Few if any distros ship with Rust’s toolset installed, and the officially recommended way to install it, this is from rust-lang.org…is to pipe curl into sh. Don’t ask end users to install a programming language to compile your software.
Go ahead and ask your fellow developers to compile your software; that’s how contributing and forking and all that open source goodness should be done. But not end users. Not for “Install and use as intended.” For that, distribute a compiled binary somehow; at the very least a dockerfile if a service or an appimage if an application. Don’t make people who don’t develop in Rust install the Rust compiler.
For people who do this, is the purpose to ensure you are not getting a bad binary which has some malicious code compiled in?
If yes, isn’t it more difficult to check all the source code yourself? You may as well trust a binary where the author has confirmed a hash of the binary. Unless you really are checking every single line of source code. But then I wonder how you get anything else done.
The incident from
xzgives a good example of where self-compiling stuff would be a good idea.The code was mostly fine, but the maintainer managed to include malicious instructions in the binary. Most people who read the source, didn’t realise the possibility. I checked it out afterwards and it was still hard to get.
The idea is that someone is checking the code. And by building it yourself, you can at least ensure that you’re getting what’s built from the code. It is possible that some malicious stuff was inserted while building the binary that doesn’t show up in the source code. Building from source solves that problem.
Reproducible builds try to solve that problem by generating some provenance from a third party. A middle ground can be building the binary using something like GitHub Actions, since that can be audited by others. That comes with its own can of worms since GH is owned by M$, but I digress.
So it is technically sane to do it, just not very practical in my view. But for lesser known apps, I do sometimes build from source.
Yeah, the good tooling also means it isn’t even terribly difficult for the dev to provide builds, but it isn’t quite as automated as publishing to crates.io, so many don’t bother with automating or manually uploading…
cargo install xyzandapt install xyzaren’t mutually exclusive.Pypi isn’t in any way less an option for distributing software countless projects that use it that way can be used as a proof. Hell, awscli installed from pypi for ages. In my experience cargo is extremely slow at downloading hundred libraries that every program needs and rustc is extremely slowly builds them.
Correction, uv isn’t in any way less an option. pypi is only the registry. If you are using pip you will end up in dependency hell, you might use something like poetry to avoid that, but uv is just better.
But… wait a minute… uv is inspired by cargo, and it’s also written in rust. That’s quite the coincidence, huh?
Also, cargo is fast, it’s rustc that’s slow, and that’s because rustc is doing advanced code analysis. Compiling rust is actually NP-hard, but in exchange for that, the compiler will catch bugs in place of the developer. Which is a good tradeoff considering that you only compile once and run many times.
“countless projects that use it that way” isn’t proof of anything. Countless projects tell you to
curla 2000 lines script intosudo bashthat will fill your os with bullshit.Pip is a sane default that works for absolute majority of cases, anyway correct tool for installing programs from pypi is pipx that eliminates ‘dependency hell’, but ofc new cool tool is the only way to do things.
When little program in rust that replaced previous one compiles two hours compared to previous that compiled in a few minutes it matters.
UV is a lot more than pipx. It installs applications from pypi, without dependency hell, but it also uses hard links when possible to avoid wasting space. But it’s also a dev tool. It manages python installations, workspaces, you can use it to edit the pyproject, it can also publish to pypi, even from a GitHub action if set up from pypi. It just does a lot more.
I know what uv is, also never felt the need for package manager do a lot more. Just not my use case, pip + pipx is enough for me. I do develop in python but I’m trying to do it as tidy as possible without any or minimal external deps due to environment constraints, maybe for web dev or other fields where there is a need to install billion external libraries and multiple versions of them uv is a right choice, who knows. Personally I would prefer first party tool.
None of the issues you’ve described are Cargo’s fault. The long compilation time is simply rustc’s compile-time checks (ensuring type and memory safety is much more involved than lexing in GCC), and the number of dependencies to compile is a result of the crate ecosystem. Cargo is just the front-end that automates fetching dependencies and compilation with rustc. Blaming it for slow compilation is like hitting your monitor when the computer is acting up.
I’m not blaming cargo specifically for building it is slow to download deps as well, which was clearly stated in my first post. I’m going to edit it now.
The Rust compiler is more sophisticated than most compilers, so it can be slower at the same kind of tasks. But it also just does a different task here.
One of the tradeoffs in Rust’s design is that libraries get compiled specifically for a concrete application. So, whereas in most programming languages, you just download pre-compiled libraries, in Rust, you actually download their source code and compile all of it on your machine.
This isn’t relevant, if you get a pre-built binary. And it’s not particularly relevant during development either, because you get incremental compilation. But yeah, if someone wants to compile a Rust codebase from scratch, then they have to sit through a long build.