(I did write the book, yes :) )

> 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.

> Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software.

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.

> 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.

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.

[1] - https://github.com/BurntSushi/ripgrep#installation

Sorry, I didn't mean to imply that cargo was the primary distribution method, merely that it was one and that cargo has gone well beyond being a build tool. Rereading the comment I can see how you interpreted it that way. I could have been any app built, ripgrep was just the only one that came to mind.

We have resisted adding features to Cargo that would make it better for end-user distribution, and the RFC for "cargo install" made it explicit that it's a non-goal. It's for distributing stuff for Rust developers, like additional Cargo commands, not for general end-users.

What's the policy of crates then? It's clearly being used here as a way of distributing end-user software. If node is anything to go by then this will only increase.