3 ms·

Homebrew is dog-slow. If this becomes yet another Rust tool that is 10x faster than the one that it replaces: great.

bhouston 2y ago
I use homebrew constantly but the only part I find slow is the custom installations of the software and the lack of downloading while installing? Neither of these is related to the implementation language. What part of the home brew experience do you find slow? eg... % time brew upgrade brew upgrade 0.75s user 0.16s system 68% cpu 1.337 total % time brew list brew list 0.01s user 0.02s system 57% cpu 0.054 total
- silverwind 2y ago
  The slowness comes from its serialized downloads and package installations. If you install a thing that has 10 dependencies, those 10 dependencies will serially install, likely taking many seconds.
rafram 2y ago
Homebrew is 99% IO-bound and this will be too. Installing (prebuilt) packages doesn't require much logic. If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. The issue is finding a hosting provider willing to be DDOS'd for the good of the open-source community.
- MrBuddyCasino 2y ago
  > If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. If this is true, why are the Rust tools, on average, so much faster than the JS (or whatever) tools they replace? Hint: the answer hasn't just to do with the theoretical technical merits of the underlying platform, but also what type of developer they attract.
  - frollogaston 2y ago
    Do you have an example of a faster Rust tool that replaced an IO-bound JS tool? The toolchain ones that got Rust replacements were CPU-bound afaik.
- IshKebab 2y ago
  Hmm I'm sure people said that about Pip before uv came along and was literally 10x faster. To be fair I haven't noticed Brew being as tediously slow as Pip. Maybe I just use it way less.
  - woodruffw 2y ago
    There are two things that work in `uv`'s favor (which, to be clear, is an incredible tool that I'm a big fan of): 1. Python packaging, unlike Homebrew, does have a compute-heavy phase in the form of dependency resolution. `uv` can make significant gains over `pip` in that phase. 2. `uv` performs parallel downloads and other operations, in part because of Rust's fearless parallelism. Homebrew doesn't really have (1), since resolution is just a linearization of the dependency tree. And parallelism of downloads in (2) poses a problem for Homebrew that's been mentioned in other threads (whereas parallelism is not a significant problem for PyPI's CDN-fronted distribution).
    - frollogaston 2y ago
      Python should be able to do parallel downloads at least, albeit having the overhead of multiple OS threads unless you're using asyncio.
      - woodruffw 2y ago
        Yep. The limitation in pip is architectural, not on Python's own side. However, there's been some progress there recently[1]. [1]: https://github.com/pypa/pip/issues/825 https://github.com/pypa/pip/issues/825

I use homebrew constantly but the only part I find slow is the custom installations of the software and the lack of downloading while installing? Neither of these is related to the implementation language. What part of the home brew experience do you find slow? eg... % time brew upgrade brew upgrade 0.75s user 0.16s system 68% cpu 1.337 total % time brew list brew list 0.01s user 0.02s system 57% cpu 0.054 total

silverwind 2y ago
The slowness comes from its serialized downloads and package installations. If you install a thing that has 10 dependencies, those 10 dependencies will serially install, likely taking many seconds.

rafram 2y ago

Homebrew is 99% IO-bound and this will be too. Installing (prebuilt) packages doesn't require much logic. If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. The issue is finding a hosting provider willing to be DDOS'd for the good of the open-source community.

MrBuddyCasino 2y ago
> If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. If this is true, why are the Rust tools, on average, so much faster than the JS (or whatever) tools they replace? Hint: the answer hasn't just to do with the theoretical technical merits of the underlying platform, but also what type of developer they attract.
- frollogaston 2y ago
  Do you have an example of a faster Rust tool that replaced an IO-bound JS tool? The toolchain ones that got Rust replacements were CPU-bound afaik.
IshKebab 2y ago
Hmm I'm sure people said that about Pip before uv came along and was literally 10x faster. To be fair I haven't noticed Brew being as tediously slow as Pip. Maybe I just use it way less.
- woodruffw 2y ago
  There are two things that work in `uv`'s favor (which, to be clear, is an incredible tool that I'm a big fan of): 1. Python packaging, unlike Homebrew, does have a compute-heavy phase in the form of dependency resolution. `uv` can make significant gains over `pip` in that phase. 2. `uv` performs parallel downloads and other operations, in part because of Rust's fearless parallelism. Homebrew doesn't really have (1), since resolution is just a linearization of the dependency tree. And parallelism of downloads in (2) poses a problem for Homebrew that's been mentioned in other threads (whereas parallelism is not a significant problem for PyPI's CDN-fronted distribution).
  - frollogaston 2y ago
    Python should be able to do parallel downloads at least, albeit having the overhead of multiple OS threads unless you're using asyncio.
    - woodruffw 2y ago
      Yep. The limitation in pip is architectural, not on Python's own side. However, there's been some progress there recently[1]. [1]: https://github.com/pypa/pip/issues/825 https://github.com/pypa/pip/issues/825