Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nanobrew: The fastest macOS package manager compatible with brew

nanobrew.trilok.ai

Post reply on HN
Print view View original

121–130 of 156 posts

Re: Nanobrew: The fastest macOS package manager compatible with brew

#121

Post by what »

saghm wrote: post #90
swiftcoder wrote: post #15

Earlier quoted context omitted.

> 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

I'm not sure if I just have way fewer things installed than most people or I just update more often, but I haven't experienced anything like this for years. I run `brew upgrade` probably around once every (work)day, usually right before doing a git pull or something, and then I'll quickly look at a couple emails or slack messages, and then it's always done by the time I switch back

What? Why are you running brew upgrade every day?

Re: Nanobrew: The fastest macOS package manager compatible with brew

#122

Post by SlightlyLeftPad »

novok wrote: post #65
petcat wrote: post #41

Earlier quoted context omitted.

Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow. It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated. Glad to hear a Rust rewrite is coming to Homebre…

Ruby doesn't have to be the slow part, bazel uses starlark which is mostly python and it's very fast.

Bazel has other problems

Re: Nanobrew: The fastest macOS package manager compatible with brew

#123

Post by SlightlyLeftPad »

joemi wrote: post #117
SOLAR_FIELDS wrote: post #22

Earlier quoted context omitted.

Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon

Is Ruby really the speed bottleneck in Homebrew? I would assume it would be due to file operations (and download operations), not choice of programming language.

Largely agree, though some things are notably difficult in some languages. Things like true concurrency for example didn’t come as naturally in Ruby because of the global interpreter lock. Of course there are third party libs, and workarounds though. Newer versions of Ruby bring it more natively, and as we’ve seen, Homebrew has adopted and makes use of that experimentally for a while, and the default relatively recently.

I can’t say that’s the only reason it’s slow of course. I’m on the “I don’t use it often enough for it to be a problem at all” side of the fence.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#126

Post by SlightlyLeftPad »

ukuina wrote: post #124
SlightlyLeftPad wrote: post #122

Earlier quoted context omitted.

Bazel has other problems

Could you elaborate?

Sure,

* it’s purpose built for mega-sized monorepo models like Google (the same company that created it)

* it’s not at all beginner friendly, it’s complex mishmash of three separate constructs in their own right (build files, workspace setup, starlark), which makes it slow to ramp new engineers on.

* even simple projects require a ton of setup

* requires dedicated remote cache to be performant, which is also not trivial to configure

* requires deep bazel knowledge to troubleshoot through its verbose unclear error logs.

Because of all that, it’s extremely painful to use for anything small/medium in scale.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#127

Post by waterTanuki »

mikemcquaid wrote: post #6

If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…

> Homebrew is working on an official Rust frontend that will actually have full compatibility. Hopefully this will help share effort across the wider ecosystem.

Where can I read more on this effort?

Re: Nanobrew: The fastest macOS package manager compatible with brew

#128

Post by zerd »

rconti wrote: post #70
drob518 wrote: post #7

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.

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.

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.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#130

Post by mikemcquaid »

derefr wrote: post #99
mikemcquaid wrote: post #6

If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…

> Homebrew is working on an official Rust frontend that will actually have full compatibility. When you say "Rust frontend", is the vision that Homebrew's frontend would eventually transition to being a pure Rust project — no end-user install of portable-ruby and so forth? If so (ignore everything below if not): I can see how that would work for most "boring" formulae: formula JSON gets pre-baked at formula publish t…

We will never be 100% Rust an 0% Ruby. It’s possible that 99% of users end up never running any Ruby, though. It’ll still be needed for local development and our CI. We’re optimising for speeding up the 99% case as much as possible.
Post reply on HN