3 ms·

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 1

by 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

by rafram 2y ago

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