6 ms·

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 secon

by drob518 7mo ago

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.

motorpixel 7mo ago
If I have to deal with even the mention of another package manager in the cross-platform dev ecosystem I am going to snap
pxc 7mo ago
If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.
dilap 7mo ago
Horses for courses, but I've stopped using brew 'cuz it's too slow, so this might bring me back! Edit: no, it won't...
- drob518 7mo ago
  Agreed on horses for courses. Different people have different tolerances. And yea, all things being equal, faster is better, but they are almost never equal. If you don’t mind me asking, what does “too slow” mean for you in this context? Do you have a particularly complex setup? And what do you use now as an alternative and how has that impacted the update speed?
  - dilap 7mo ago
    I wish I could remember the details -- I know I got annoyed with things being slow and when I got a new computer decided to go the no-homebrew route. I'm using nix, and it seems fine so far, but I also really don't understand it at all, which is a little concerning. :-)
swiftcoder 7mo ago
> I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update I definitely have thought something along those lines (mostly when I go to install a small tool, and get hit with 20 minutes of auto-updates first). Pretty sure I also will not be adopting this particular solution, however
- bombcar 7mo ago
  I've never thought "only 2 seconds faster" - I've certainly thought "why is this taking half the time it takes Gentoo to recompile an entire server".
- SOLAR_FIELDS 7mo ago
  FWIW this seems to have improved in recent years. Back in the dark times of non parallelized downloads I would purposefully wait to end of day and fire the thing off before leaving
- joshstrange 7mo ago
  But you can turn that behavior off, IIRC it tells you the environment variable to set if you don’t want it to do that every time it runs. I agree it’s annoying, but I haven’t turned it off because it’s only annoying because I’m not keeping my computer (brew packages) up-to-date normally (aka, it’s my own fault).
  - slackfan 7mo ago
    Terrible default behavior is a great reason to abandon a software package.
  - swiftcoder 7mo ago
    I'd be much happier if it were on a background job, than arbitrarily running when I invoke a command
    - menno-sh 7mo ago
      I've started using https://github.com/DomT4/homebrew-autoupdate https://github.com/DomT4/homebrew-autoupdate recently, which has been great.
mproud 7mo ago
My brew update/upgrade takes forever
noahbp 7mo ago
The same criticism has been said of Deno and Pnpm and bun, and yet, despite all these years since their respective releases, node and npm remain slower than all three options.
- never_inline 7mo ago
  Well, pnpm solves the storage issue, which is a more pressing reason to use it. (I don't know about deno/bun)
- fleebee 7mo ago
  Yeah, but do they work? Last time I gave bun a chance their runtime had serious issues with frequent crashes. Faster package installation or spin-up time is meaningless if it comes at the cost of stability and compatibility.
  - alwillis 7mo ago
    bun is my go to for npm packages; it’s so much better and faster than npm, it’s not funny. Never had any issues.
ziml77 7mo ago
Agreed here. The speed bottleneck I run into is simply that there's often a lot of packages that need updating, so there's a lot to download. And if anything needs to be compiled from source then the time that takes will dominate (though I think everything I currently run is thankfully pre-built)
staticassertion 7mo ago
I've wanted brew to be faster. It would be a nice QoL for me.
password4321 7mo ago
See also: asdf and mise https://github.com/asdf-vm/asdf/issues/290#issuecomment-2365369222 https://github.com/asdf-vm/asdf/issues/290#issuecomment-2365...
rconti 7mo ago
I've been a lightweight homebrew user for many, many, many years now. I just use it to download or update a thing I need, once every 3-6mo. It constantly blows my mind how insanely long it takes just to do a few simple things on the fastest hardware I've ever owned in my life.
- zerd 7mo ago
  It's ok because I rarely need it, but sometimes it's so slow I'm looking for alternative install methods while it's doing it's thing.
devkarev 7mo ago
[dead]
saghm 7mo ago
Brew definitely used to be a lot slower, and I used to find it very tedious. I feel like they've done a reasonably good job in improving that over the years though (with the switch to distributing binaries by default being a huge win in terms of speed). I have to wonder if stuff like this is more due to lingering feelings from before combined with the easy access to vibe coding tools. If LLM coding came a few years earlier, maybe projects like this one would have made more sense to me.
karel-3d 7mo ago
I definitely have felt this. Homebrew is slow. However, this is a vibe-coded app, with around 30 commits per day, which I don't let install packages on my machine.
bobbylarrybobby 7mo ago
I have definitely wished that Homebrew would not wait for all packages to be downloaded before pouring them. It's nice that downloads happen in parallel (didn't always used to be the case iirc), but it feels like the pouring could also be done in the same parallel workflow.

by drob518 7mo ago

motorpixel 7mo ago

If I have to deal with even the mention of another package manager in the cross-platform dev ecosystem I am going to snap

pxc 7mo ago

If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.

dilap 7mo ago

Horses for courses, but I've stopped using brew 'cuz it's too slow, so this might bring me back! Edit: no, it won't...

drob518 7mo ago
Agreed on horses for courses. Different people have different tolerances. And yea, all things being equal, faster is better, but they are almost never equal. If you don’t mind me asking, what does “too slow” mean for you in this context? Do you have a particularly complex setup? And what do you use now as an alternative and how has that impacted the update speed?
- dilap 7mo ago
  I wish I could remember the details -- I know I got annoyed with things being slow and when I got a new computer decided to go the no-homebrew route. I'm using nix, and it seems fine so far, but I also really don't understand it at all, which is a little concerning. :-)

swiftcoder 7mo ago

> I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update I definitely have thought something along those lines (mostly when I go to install a small tool, and get hit with 20 minutes of auto-updates first). Pretty sure I also will not be adopting this particular solution, however

bombcar 7mo ago
I've never thought "only 2 seconds faster" - I've certainly thought "why is this taking half the time it takes Gentoo to recompile an entire server".
SOLAR_FIELDS 7mo ago
FWIW this seems to have improved in recent years. Back in the dark times of non parallelized downloads I would purposefully wait to end of day and fire the thing off before leaving
joshstrange 7mo ago
But you can turn that behavior off, IIRC it tells you the environment variable to set if you don’t want it to do that every time it runs. I agree it’s annoying, but I haven’t turned it off because it’s only annoying because I’m not keeping my computer (brew packages) up-to-date normally (aka, it’s my own fault).
- slackfan 7mo ago
  Terrible default behavior is a great reason to abandon a software package.
- swiftcoder 7mo ago
  I'd be much happier if it were on a background job, than arbitrarily running when I invoke a command
  - menno-sh 7mo ago
    I've started using https://github.com/DomT4/homebrew-autoupdate https://github.com/DomT4/homebrew-autoupdate recently, which has been great.

mproud 7mo ago

My brew update/upgrade takes forever

noahbp 7mo ago

The same criticism has been said of Deno and Pnpm and bun, and yet, despite all these years since their respective releases, node and npm remain slower than all three options.

never_inline 7mo ago
Well, pnpm solves the storage issue, which is a more pressing reason to use it. (I don't know about deno/bun)
fleebee 7mo ago
Yeah, but do they work? Last time I gave bun a chance their runtime had serious issues with frequent crashes. Faster package installation or spin-up time is meaningless if it comes at the cost of stability and compatibility.
- alwillis 7mo ago
  bun is my go to for npm packages; it’s so much better and faster than npm, it’s not funny. Never had any issues.

ziml77 7mo ago

Agreed here. The speed bottleneck I run into is simply that there's often a lot of packages that need updating, so there's a lot to download. And if anything needs to be compiled from source then the time that takes will dominate (though I think everything I currently run is thankfully pre-built)

staticassertion 7mo ago

I've wanted brew to be faster. It would be a nice QoL for me.

password4321 7mo ago

See also: asdf and mise https://github.com/asdf-vm/asdf/issues/290#issuecomment-2365369222 https://github.com/asdf-vm/asdf/issues/290#issuecomment-2365...

rconti 7mo ago

I've been a lightweight homebrew user for many, many, many years now. I just use it to download or update a thing I need, once every 3-6mo. It constantly blows my mind how insanely long it takes just to do a few simple things on the fastest hardware I've ever owned in my life.

zerd 7mo ago
It's ok because I rarely need it, but sometimes it's so slow I'm looking for alternative install methods while it's doing it's thing.

devkarev 7mo ago

[dead]

saghm 7mo ago

Brew definitely used to be a lot slower, and I used to find it very tedious. I feel like they've done a reasonably good job in improving that over the years though (with the switch to distributing binaries by default being a huge win in terms of speed). I have to wonder if stuff like this is more due to lingering feelings from before combined with the easy access to vibe coding tools. If LLM coding came a few years earlier, maybe projects like this one would have made more sense to me.

karel-3d 7mo ago

I definitely have felt this. Homebrew is slow. However, this is a vibe-coded app, with around 30 commits per day, which I don't let install packages on my machine.

bobbylarrybobby 7mo ago

I have definitely wished that Homebrew would not wait for all packages to be downloaded before pouring them. It's nice that downloads happen in parallel (didn't always used to be the case iirc), but it feels like the pouring could also be done in the same parallel workflow.