5 ms·

I think Cargo doubling as both build tool and package manager is a big factor here. The combination of Cargo + crates.io makes it very easy to write some Rust c

I think Cargo doubling as both build tool and package manager is a big factor here. The combination of Cargo + crates.io makes it very easy to write some Rust code and make it available to anyone with Cargo on their system. Either by `cargo install nu` to build it from sources on crates.io or `cargo install` inside the git repo to build my own customized version. No more waiting for distro packagers to keep up. Putting this together makes for a nice environment to distribute native system tools. And in the last few years we've seen a wave of these tools becoming popular (ripgrep, bat, fzf, broot, exa and some others).

spullara 5y ago
How are you measuring popularity?
- vbsteven 5y ago
  Popularity in this context is my personal experience seeing these tools pop up over and over again in the media that I consume.
chx 5y ago
This is insanity and hubris. "It's so easy!" yes if you have the language and tools de jour installed and up to date. I want none of that. It was node and npm. Then go. Now Rust and cargo. Oh, I forgot ruby. And all this needs to be up to date or things break. (And if you do update them then things you are actively using will break.) I don't need more tamagochis, in fact the less I have, the better. What happened to .deb and .rpm files? Especially since these days you can have github actions or a gitlab pipeline packaging for you. I can't care less what language you are using, don't try to force it down my throat.
- stevenhuang 5y ago
  Why don't you download the native binaries then? Rust isn't an interpreted language, you only need the rust toolchain if you want to build from source.
  - vkoskiv 5y ago
    Binary releases seem uncommon from my perspective. Every time I go to install a piece of software written in Rust from homebrew, it invariably starts installing some massive Rust toolchain as a dependency, at which point I give up and move on. Maybe it's a case of the packagers taking a lazy route or something, or maybe there is a reason for depending on cargo. I have no idea.
    - indemnity 5y ago
      Do you have some specific examples? E.g. ripgrep is packaged on most operating systems I have used, along with exa, and a few other Rust utils I use. I certainly do not use Cargo to install them.
      - vkoskiv 5y ago
        Perhaps the packagers on your platform went that extra mile to build binary packages. Taking a quick look, the Homebrew formula[0] for ripgrep on macOS just lists a dependency on Cargo (rust) and then seems to invoke the cargo command for installation. I'm not well versed in Ruby though, so my interpretation could be wrong. I don't want to come off as entitled, either. I know the Homebrew folks are doing a ton of brilliant, ongoing work to make it work as well as it does, so I can't really blame them for potentially taking a shortcut here. [0] https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/ripgrep.rb https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/...
        burntsushi 5y ago
        If it installs a bottle, then does it still require installing Rust? If so, then maybe that's a shortcoming of Homebrew. Either way, it kinda seems like you're complaining about Homebrew here. Not Rust. If having Cargo/Rust on your system is really a Hard No (...why?), then I guess find a package manager that only delivers whatever is necessary, or, if available, use the project's binary releases: https://github.com/BurntSushi/ripgrep/releases/tag/13.0.0 https://github.com/BurntSushi/ripgrep/releases/tag/13.0.0 And actually, in the case of ripgrep, it provides a Homebrew tap that specifically uses the GitHub release binary: https://github.com/BurntSushi/ripgrep/blob/master/pkg/brew/ripgrep-bin.rb https://github.com/BurntSushi/ripgrep/blob/master/pkg/brew/r...
- pdpi 5y ago
  Ease of use and familiarity are different things. Tooling around rust really is easy, when the alternatives (for equivalent languages) are CMake, autotools, and the like. As it stands, I can brew install ripgrep and it just works. I don’t need to know it’s written it rust. If, for some reason, homebrew (or whatever other package manager) is lagging behind and I need a new release now, cargo install is a much easier alternative compared to, again, other tools built in equivalent languages
  - xpe 5y ago
    Indeed. Thank for you stating this so clearly. The "ease of use" and "familiarity" distinction reminds me of talks by people such as Rich Hickey who distinguish "simple" and "easy": https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/ > Rich Hickey emphasizes simplicity’s virtues over easiness’, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.
- aldanor 5y ago
  Ruby requires an interpreter at runtime. JavaScript too. Rust produces standalone binaries. So no, "things don't break" and you only compile things once. // I can't care less about deb or rpm files so don't try to force that down my throat.
  - pjmlp 5y ago
    It is Gentoo all over again.
  - hnlmorg 5y ago
    There's no win/win scenario when comparing libraries to static binaries. On the one hand, static binaries are more user friendly. But they remove the responsibility for keeping your OS secure away from the OS/distro maintainers. For example, if a vulnerability is found in a create, you then have to hope that every maintainer who manages a Rust project that imports said create diligently pushes out newer binaries quickly. You then have multiple applications that need to be updated rather than one library. This may well be a future problem we'll end up reading more about as Rust, Go and others become more embedded in our base Linux / macOS / etc install.
- j1elo 5y ago
  100% agree. I find it very funny, but in a sarcastic and totally wrong way, when a project's README has an Install section that reads: Run "cargo install myProject" I know Rust, so Cargo is not alien to me. But come on, you know that your install instructions are a bit shitty. Please, choose a target distro, then test your instructions in a clean Docker container. THEN you can sit down knowing you wrote proper guidance for users. EDIT because this comment is being misunderstood: I meant that you should make sure your instructions work as-is from a clean installation of your intended distro(s), regardless of how you prefer to do so; using a Docker container is just my preferred method, but you can also do a clean VM or whatever else, as long as you don't assume anything beyond a default installed system.
  - qmmmur 5y ago
    Hold on, do you not see the insane contradiction of not wanting to rely on having cargo installed but requiring something is deployable and tested in a docker container? What?!
    - mouldysammich 5y ago
      If its deployable and tested in a docker container its much easier to generate user images, it takes the onus away from the user and the developer can just put it on the aur/publish a deb
    - j1elo 5y ago
      No, you misunderstood. I meant that if you're going to document a block of command-line instructions, you should first make sure those commands work as-is in a clean system. A very easy way to do this (for me anyways) is using a Docker container. I use this method to test all of my documented commands. But there are other ways, of course, like using a clean VM. Regardless, just test the commands without assuming the customized state of your own workstation! The point is that if I follow the hypothetical instructions of running "cargo install something", the result will probably be "cargo: command not found". When you test this in a clean system and find this error message, this places on you the burden of depending on Cargo, so the least you should do is to make sure "cargo" will work for the user who is reading your docs. At a minimum, you should link to somewhere that explains how to install Cargo. tldr: you should make sure your instructions work as-is from a clean installation of your intended distro(s), regardless of how you prefer to do so.
- CJefferson 5y ago
  The problem with .deb and .rpm is your dependencies, some things aren't packaged, you end up having to build separate packages for each major Debian and redhat release to link against the correct dependency version. I'd love that to all be "one-command automated", but I haven't seen such a thing, unlike cargo, which I do find I can be productive with after a one page tutorial.
- fauigerzigerk 5y ago
  I agree that it's not ideal, but unfortunately bad decisions by Linux distributions and package maintainers have trained me as a user to avoid the package managers if I want up to date software with predictable and documented defaults.
- chriswarbo 5y ago
  > What happened to .deb and .rpm files? The problem with those is they require global consistency. If one package needs libfoo-1.1 (or at least claims to), but something else needs libfoo-1.2+, we can't install both packages. It doesn't take long (e.g. 6 months to a year) before distro updates break one-off packages. I think some people try hacking around this by installing multiple operating systems in a pile containers, but that sounds awful. My preferred solution these days is Nix, which I think of as a glorified alternative/wrapper for Make: it doesn't care about language, "packages" can usually be defined using normal bash commands, and it doesn't require global consistency (different versions of things can exist side by side, seen only by packages which depend on them).
- andrewzah 5y ago
  Many of the popular rust cli tools like ripgrep, exa, delta, etc -do- have package manager install options. How dare people writing cli tools not package them conveniently for my distro. The horror of using cargo instead of cloning the source and praying make/meson/etc works. Feel free to package and maintain these tools yourself for your distro if you want.
  - ghoward 5y ago
    I don't know about you, but in my experience, getting Cargo to work has been a much bigger pain than make/meson et al.
    - andrewzah 5y ago
      I've never had any issues with cargo. I use rustup to manage my rust toolchains and cargo for the most part.
- vbsteven 5y ago
  I'm the parent that you replied to. In my eyes there is nothing wrong with .deb and .rpm files. In fact, many of these tools are available for download in these formats and some others (docker, snap, etc). And it is good that they do but it comes with extra work to setup the pipelines/builds. The concept of a language-specific package manager distributing not only libraries but also executables isn't new. Go get, ruby bundler, python pip, cargo and npm all have this feature. I was originally answering a question about why we suddenly see all these "written in Rust" tools pop up. I think that is partly because Cargo provides this easier way to distribute native code to users on various platforms, without jumping through additional hoops like building a .deb, and setting up an apt repository. Sometimes you just want to get some code out there into the world, and if the language ecosystem you are in provides easy publishing tools, why not use them for the first releases? And if later your tool evolves and becomes popular, the additional packaging for wider distribution can be added.
- Macha 5y ago
  You happen to have cmake or autotools installed, others happen to have cargo installed. Once cargo/cmake/autotools/make/npm/mvn/setup.py/whatever runs, the process of taking the output and packaging it for your preferred distro is the same. There's more work involved if you want a distro to actually pick it up and include it in their repos around not using static linking, but if you're asking for a .deb/.rpm on github actions, that's not needed.
vogon_laureate 5y ago
Thank you for listing these. I had a look at them and they are really useful utilities. Now the challenge is to try to change the muscle memory that relies on the traditional unix commands!

spullara 5y ago

How are you measuring popularity?

vbsteven 5y ago
Popularity in this context is my personal experience seeing these tools pop up over and over again in the media that I consume.

chx 5y ago

This is insanity and hubris. "It's so easy!" yes if you have the language and tools de jour installed and up to date. I want none of that. It was node and npm. Then go. Now Rust and cargo. Oh, I forgot ruby. And all this needs to be up to date or things break. (And if you do update them then things you are actively using will break.) I don't need more tamagochis, in fact the less I have, the better. What happened to .deb and .rpm files? Especially since these days you can have github actions or a gitlab pipeline packaging for you. I can't care less what language you are using, don't try to force it down my throat.

stevenhuang 5y ago
Why don't you download the native binaries then? Rust isn't an interpreted language, you only need the rust toolchain if you want to build from source.
- vkoskiv 5y ago
  Binary releases seem uncommon from my perspective. Every time I go to install a piece of software written in Rust from homebrew, it invariably starts installing some massive Rust toolchain as a dependency, at which point I give up and move on. Maybe it's a case of the packagers taking a lazy route or something, or maybe there is a reason for depending on cargo. I have no idea.
  - indemnity 5y ago
    Do you have some specific examples? E.g. ripgrep is packaged on most operating systems I have used, along with exa, and a few other Rust utils I use. I certainly do not use Cargo to install them.
    - vkoskiv 5y ago
      Perhaps the packagers on your platform went that extra mile to build binary packages. Taking a quick look, the Homebrew formula[0] for ripgrep on macOS just lists a dependency on Cargo (rust) and then seems to invoke the cargo command for installation. I'm not well versed in Ruby though, so my interpretation could be wrong. I don't want to come off as entitled, either. I know the Homebrew folks are doing a ton of brilliant, ongoing work to make it work as well as it does, so I can't really blame them for potentially taking a shortcut here. [0] https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/ripgrep.rb https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/...
      - burntsushi 5y ago
        If it installs a bottle, then does it still require installing Rust? If so, then maybe that's a shortcoming of Homebrew. Either way, it kinda seems like you're complaining about Homebrew here. Not Rust. If having Cargo/Rust on your system is really a Hard No (...why?), then I guess find a package manager that only delivers whatever is necessary, or, if available, use the project's binary releases: https://github.com/BurntSushi/ripgrep/releases/tag/13.0.0 https://github.com/BurntSushi/ripgrep/releases/tag/13.0.0 And actually, in the case of ripgrep, it provides a Homebrew tap that specifically uses the GitHub release binary: https://github.com/BurntSushi/ripgrep/blob/master/pkg/brew/ripgrep-bin.rb https://github.com/BurntSushi/ripgrep/blob/master/pkg/brew/r...
pdpi 5y ago
Ease of use and familiarity are different things. Tooling around rust really is easy, when the alternatives (for equivalent languages) are CMake, autotools, and the like. As it stands, I can brew install ripgrep and it just works. I don’t need to know it’s written it rust. If, for some reason, homebrew (or whatever other package manager) is lagging behind and I need a new release now, cargo install is a much easier alternative compared to, again, other tools built in equivalent languages
- xpe 5y ago
  Indeed. Thank for you stating this so clearly. The "ease of use" and "familiarity" distinction reminds me of talks by people such as Rich Hickey who distinguish "simple" and "easy": https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/ > Rich Hickey emphasizes simplicity’s virtues over easiness’, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.
aldanor 5y ago
Ruby requires an interpreter at runtime. JavaScript too. Rust produces standalone binaries. So no, "things don't break" and you only compile things once. // I can't care less about deb or rpm files so don't try to force that down my throat.
- pjmlp 5y ago
  It is Gentoo all over again.
- hnlmorg 5y ago
  There's no win/win scenario when comparing libraries to static binaries. On the one hand, static binaries are more user friendly. But they remove the responsibility for keeping your OS secure away from the OS/distro maintainers. For example, if a vulnerability is found in a create, you then have to hope that every maintainer who manages a Rust project that imports said create diligently pushes out newer binaries quickly. You then have multiple applications that need to be updated rather than one library. This may well be a future problem we'll end up reading more about as Rust, Go and others become more embedded in our base Linux / macOS / etc install.
j1elo 5y ago
100% agree. I find it very funny, but in a sarcastic and totally wrong way, when a project's README has an Install section that reads: Run "cargo install myProject" I know Rust, so Cargo is not alien to me. But come on, you know that your install instructions are a bit shitty. Please, choose a target distro, then test your instructions in a clean Docker container. THEN you can sit down knowing you wrote proper guidance for users. EDIT because this comment is being misunderstood: I meant that you should make sure your instructions work as-is from a clean installation of your intended distro(s), regardless of how you prefer to do so; using a Docker container is just my preferred method, but you can also do a clean VM or whatever else, as long as you don't assume anything beyond a default installed system.
- qmmmur 5y ago
  Hold on, do you not see the insane contradiction of not wanting to rely on having cargo installed but requiring something is deployable and tested in a docker container? What?!
  - mouldysammich 5y ago
    If its deployable and tested in a docker container its much easier to generate user images, it takes the onus away from the user and the developer can just put it on the aur/publish a deb
  - j1elo 5y ago
    No, you misunderstood. I meant that if you're going to document a block of command-line instructions, you should first make sure those commands work as-is in a clean system. A very easy way to do this (for me anyways) is using a Docker container. I use this method to test all of my documented commands. But there are other ways, of course, like using a clean VM. Regardless, just test the commands without assuming the customized state of your own workstation! The point is that if I follow the hypothetical instructions of running "cargo install something", the result will probably be "cargo: command not found". When you test this in a clean system and find this error message, this places on you the burden of depending on Cargo, so the least you should do is to make sure "cargo" will work for the user who is reading your docs. At a minimum, you should link to somewhere that explains how to install Cargo. tldr: you should make sure your instructions work as-is from a clean installation of your intended distro(s), regardless of how you prefer to do so.
CJefferson 5y ago
The problem with .deb and .rpm is your dependencies, some things aren't packaged, you end up having to build separate packages for each major Debian and redhat release to link against the correct dependency version. I'd love that to all be "one-command automated", but I haven't seen such a thing, unlike cargo, which I do find I can be productive with after a one page tutorial.
fauigerzigerk 5y ago
I agree that it's not ideal, but unfortunately bad decisions by Linux distributions and package maintainers have trained me as a user to avoid the package managers if I want up to date software with predictable and documented defaults.
chriswarbo 5y ago
> What happened to .deb and .rpm files? The problem with those is they require global consistency. If one package needs libfoo-1.1 (or at least claims to), but something else needs libfoo-1.2+, we can't install both packages. It doesn't take long (e.g. 6 months to a year) before distro updates break one-off packages. I think some people try hacking around this by installing multiple operating systems in a pile containers, but that sounds awful. My preferred solution these days is Nix, which I think of as a glorified alternative/wrapper for Make: it doesn't care about language, "packages" can usually be defined using normal bash commands, and it doesn't require global consistency (different versions of things can exist side by side, seen only by packages which depend on them).
andrewzah 5y ago
Many of the popular rust cli tools like ripgrep, exa, delta, etc -do- have package manager install options. How dare people writing cli tools not package them conveniently for my distro. The horror of using cargo instead of cloning the source and praying make/meson/etc works. Feel free to package and maintain these tools yourself for your distro if you want.
- ghoward 5y ago
  I don't know about you, but in my experience, getting Cargo to work has been a much bigger pain than make/meson et al.
  - andrewzah 5y ago
    I've never had any issues with cargo. I use rustup to manage my rust toolchains and cargo for the most part.
vbsteven 5y ago
I'm the parent that you replied to. In my eyes there is nothing wrong with .deb and .rpm files. In fact, many of these tools are available for download in these formats and some others (docker, snap, etc). And it is good that they do but it comes with extra work to setup the pipelines/builds. The concept of a language-specific package manager distributing not only libraries but also executables isn't new. Go get, ruby bundler, python pip, cargo and npm all have this feature. I was originally answering a question about why we suddenly see all these "written in Rust" tools pop up. I think that is partly because Cargo provides this easier way to distribute native code to users on various platforms, without jumping through additional hoops like building a .deb, and setting up an apt repository. Sometimes you just want to get some code out there into the world, and if the language ecosystem you are in provides easy publishing tools, why not use them for the first releases? And if later your tool evolves and becomes popular, the additional packaging for wider distribution can be added.
Macha 5y ago
You happen to have cmake or autotools installed, others happen to have cargo installed. Once cargo/cmake/autotools/make/npm/mvn/setup.py/whatever runs, the process of taking the output and packaging it for your preferred distro is the same. There's more work involved if you want a distro to actually pick it up and include it in their repos around not using static linking, but if you're asking for a .deb/.rpm on github actions, that's not needed.

vogon_laureate 5y ago

Thank you for listing these. I had a look at them and they are really useful utilities. Now the challenge is to try to change the muscle memory that relies on the traditional unix commands!