Compiling the whole world, including dependencies is big waste of time.
I already tried to play around with workspaces to see if at least crates only get compiled once.
With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.
This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search.
Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)
Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager.
> If you're pre-building something and pushing a package for say dpkg or rpm
The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities.
> Should an OS want to bless crates, cargo does have an override for crates.io
That's a recipe for dll hell if I've ever heard one.
most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue.
If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you believe it's doing it wrong, but every package manager for every OS out there does things differently, Rust can not fix this.
> That's a recipe for dll hell if I've ever heard one.
The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there, with the cargo manifest used to generate the various package managers dependency graphs as necessary. This would probably look a lot like, or actually be an integration with, FPM.
Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app.
> I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there
Basically, but more to the point, when a bug or security issue is fixed I don't want to rely on individual programs updating their dependencies. Let's say 10 years from now the rust version of gstreamer is widely used and a security issue is discovered, I want to be able to "apt-get upgrade" and know that it's patched. This is how things work now with the c version, but this can't be done with cargo, every app using the library has to update it's dependencies and many (particularly any corporate ones) will never update. Rust might be a boon for security but cargo could undermine the effort.
Aside from that, static linking creates a tonne of bloat, memory and disk. There is a reason windows apps are often so bloated compared to their linux counterparts.
> The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I don't think that's good enough, if rust wants to be a systems language then it has to work with the system, not be a layer on top of it like java/.net/node. It can do this technically, but culturally it's looking more like node and less like c.
If I'm installed zlib for general system use, I want a package manager. If I'm installing a Rust compression library to be compiled into the program I'm working on, I want that to be managed by my build chain (especially since the version I'm using in my build may not necessarily match what I have installed on my system to run).
As another example, if someone makes a cook general purpose library using Rust, eventually it should be packaged up and shipped in the normal distro package format by the distro if it's useful. I wouldn't expect cargo to be the normal way to distribute software. It's the Rust equivalent of the old tar -zxvf package-1.2.3.tar.gz && cd package-1.2.3 && ./configure && make && make install. You can do it, but if you have a distro package, use that first.
To be clear, neither does the Rust team. You're exactly on point here.
From the getting started chapter of the rust book (which I believe you wrote?). That implies that rust can't be used without cargo right there. And I'm not seeing any libraries published as ubuntu packages.
After this conversation I thought I should expriment more with rust and it's linking options and quickly ran into an error of some sort (quite possibly a system one) trying to buils hello world with dynamic linking:
http://stackoverflow.com/questions/44012802/rustc-and-prefer...
> That implies that rust can't be used without cargo right there.
rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year.
Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. It's like the difference between Make and pbuild or a similar tool; see the parent comment about "./configure && make" vs a system package.
> And I'm not seeing any libraries published as ubuntu packages.
Debian has an entire tool, https://crates.io/crates/debcargo, which automatically re-packages a Cargo package into a .deb. Currently, they only package the Rust compiler itself and Cargo, but this work was done specifically so that programs in Rust could be included in the distro, but packaged the way distros like. They've mostly been working on that stuff; I assume by the time Buster's cut-off date happens, there'll be some stuff; I'd like to see ripgrep, personally.
I haven't used -C prefer-dynamic in a while; usually SO questions get answered relatively quickly though.
The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installation section of ripgrep (http://blog.burntsushi.net/ripgrep/#installation) "cargo install ripgrep" is an installation option.
And because static compilation is also a distribution mechanism (just not for the end user) the binaries are 10 times larger than grep, not to mention a giant GPL trap for commercial users.
Please don't misrepresent my writing. `cargo install` is NOT the primary distribution mechanism for ripgrep. The installation section starts with instructions that use standard system package managers, and only then suggests installing it using cargo if you're a Rust programmer. Why did you leave that out?
You might also consider looking at the actual README of the project[1], which lists several more installation options, including using brew, chocolatey, pacman, emerge, dnf, yum and nix. There is clearly an effort to suggest that users install ripgrep using their standard system package manager.
Some of the points you've made in this thread are valid concerns, but please don't misrepresent other peoples' hard work while you're doing it. It's extremely rude.
Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well.
If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious.
After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well.
I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.