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 have full compatibility. Hopefully this will help share effort across the wider ecosystem.

▲

yokoprime a minute ago | parent | next [-]

thank you for all you (and your co-maintainers) do for the community!

▲

runjake 6 hours ago | parent | prev | next [-]

Context for those unaware: the commenter, mikemcquaid, is the project lead for Homebrew.

▲

Xunjin 6 hours ago | parent | next [-]

Thank you, his arguments totally makes sense, only the part that makes me icky is:

> There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks.

People are free and probably do this because it is slow. Alternatives often are not a bad thing.

▲

alwillis 5 hours ago | parent | next [-]

Since I enabled HOMEBREW_DOWNLOAD_CONCURRENCY, downloads have improved for me to the point where download speed is no longer an issue.

	▲	brailsafe 4 hours ago \| parent [-]
		Good to know! I was doing this with a hacky one-liner but wasn't aware of this flag. I think the sequential build/install process is the agonizing bit though.

▲

rbanffy 3 hours ago | parent | prev | next [-]

> Alternatives often are not a bad thing.

Exactly. I’ve been using MacPorts for ages and I love it.

/me ducks.

▲

runjake 5 hours ago | parent | prev | next [-]

Point noted! I took it as a tongue-in-cheek phrasing of "agentically coded". Hopefully, that's right.

▲

jazzpush2 4 hours ago | parent | prev | next [-]

Yeah, tbh homebrew is slow as fuck. It literally took 30 minutes to install aws cli on my 2020 mbp. I will happily flock to every new version that's faster.

▲

mpalmer 3 hours ago | parent | prev | next [-]

I don't see where he said it's a bad thing, or even implied it. As I see it, he did imply that superlatives like THE FASTEST PACKAGE MANAGER aren't worth much in this environment.

▲

huflungdung 6 hours ago | parent | prev [-]

[dead]

▲

5 hours ago | parent | prev [-]

[deleted]

▲

pxc 8 hours ago | parent | prev | next [-]

It is really coll that Homebrew provides a comprehensive enough JSON API to let people build on Homebrew in useful ways without directly running Ruby, despite everything being built in a Ruby DSL. That really does seem like a "best of both worlds" deal, and it's cool that alternative clients can take advantage of that.

I didn't know about the pending, official Rust frontend! That's very interesting.

▲

SOLAR_FIELDS 8 hours ago | parent [-]

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

▲

petcat 7 hours ago | parent | next [-]

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 Homebrew soon.

▲

kelvie 5 hours ago | parent | next [-]

One of the reasons I switched to arch from debian based distros was precisely how much faster pacman was compared to APT -- system updates shouldn't take over half an hour when I have a (multi)gigabit connection and an SSD.

It was mostly precipitated by when containers came in and I was honestly shocked at how fast apk installs packages on alpine compared to my Ubuntu boxes (using apt)

	▲	akdev1l 4 hours ago \| parent [-]
		pacman is faster simply because it does less things and it supports less use cases. For example pacman does not need to validate the system for partial upgrades because those are unsupported on Arch and if the system is borked then it’s yours to fix.

▲

novok 5 hours ago | parent | prev | next [-]

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

▲

akdev1l 4 hours ago | parent | prev | next [-]

yum was slow not because of python but because of the algorithm used to solve dependencies

Anyway the python program would call into libsolv which is implemented in C.

dnf5 is much faster but the authors of the program credit the algorithmic changes and not because it is written in C++

dnf < 5 was still performing similarly to yum (and it was also implemented in python)

▲

wavemode 4 hours ago | parent [-]

> dnf < 5 was still performing similarly to yum (and it was also implemented in python)

I'm perhaps not properly understanding your comment. If the algorithmic changes were responsible for the improved speed, why did the Python version of dnf perform similarly to yum?

	▲	akdev1l 3 hours ago \| parent [-]
		Because dnf4 used the same dependency resolution as yum but they revamped it in dnf5 (it was initially supposed to be a whole new package manager with a different name)

▲

mhurron 4 hours ago | parent | prev [-]

> Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow

Because how often are you running it where it's not anything but a opportunity to take a little breather in a day? And I do mean little, the speedups being touted here are seconds.

I have the same response to the obsession with boot times, how often are you booting your machine where it is actually impacting anything? How often are you installing packages?

Do you have the same time revulsion for going to the bathroom? Or getting a glass of water? or basically everything in life that isn't instantaneous?

▲

pxc 5 hours ago | parent | prev [-]

I would guess this change builds on the existing json endpoints for package metadata but that the Ruby DSL is remaining intact.

I think how to marry the Ruby formulas and a Rust frontend is something the Homebrew devs can figure out and I'm interested to see where it goes, but I don't really care whether Ruby "goes away" from Homebrew in the end or not. It's a lovely language, so if they can keep it for their DSL but improve client performance I think that's great.

▲

derefr 3 hours ago | parent | prev | next [-]

> 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 time; Rust frontend pulls it; discovers formula is installable via bottle; pulls bottle; never needs to execute any Ruby.

But what happens in the edge-cases there — formulae with no bottles, Ruby `post_install` blocks, and so forth? (And also, how is local formula development done?)

Is the ultimate aim of this effort, to build and embed a tiny little "Formula Ruby DSL" interpreter into the Rust frontend, that supports just enough of Ruby's syntax + semantics to execute the code that appears in practice in the bodies of real formulae methods/blocks? (I personally think that would be pretty tractable, but I imagine you might disagree.)

▲

orf 7 hours ago | parent | prev | next [-]

https://github.com/Homebrew/brew/tree/main/Library/Homebrew/... for reference

▲

tfrancisl 7 hours ago | parent | prev | next [-]

I appreciate the push for an official rust frontend. I've personally been migrating (slowly) to using nix to manage my Mac's software, but there are a ton of limitations which lead me to rely on homebrew anyway. The speed ups will be appreciated.

▲

atonse 8 hours ago | parent | prev | next [-]

Heyyyy, who are you to tell us what is and isn't compatible with homebrew?

(Just kidding, thank you for creating homebrew and your continued work on it!)

	▲	samgranieri 4 hours ago \| parent [-]
		I think Max Howell created Homebrew. I think McQuaid is the current maintainer

▲

boobsbr 7 hours ago | parent | prev | next [-]

Please, don't remove bottles and casks that are blocked by Gatekeeper. :˜(

▲

halapro 7 hours ago | parent | prev [-]

Makes no sense, the wording suggests it can use Homebrew's backend, not that it's a complete alternative to Homebrew. Nobody is confused about that.

▲

akdev1l 4 hours ago | parent | next [-]

The recipes for building and installing homebrew packages are written in Ruby

You cannot really be compatible with this unless you run the Ruby as the install scripts could do whatever arbitrary computations

In reality most recipes contain a simple declarative config but nothing stops you from doing Ruby in there.

Hence to achieve total compatibility one would need to run Ruby

▲

saghm 4 hours ago | parent [-]

Is this still true since they swapped to distributing binaries rather than building from source on each install? It's been years since I last installed something from homebrew that built from source, so something that could install the same binaries would be compatible from my standpoint.

That said, it's also been a while since I've really had any huge complaints about brew's speed. I use Linux on my personal machines, and the difference in experience with my preferred Linux distro's package manager and brew used to be laughable. To their credit, nowadays, brew largely feels "good enough", so I honestly wouldn't even argue for porting from Ruby based on performance needs at this point. I suspect part of the motivation might be around concerns about relying on the runtime to be available. Brew's use of Ruby comes from a time when it was more typical for people to rely on the versions of Python and Ruby that were shipped with MacOS, but nowadays a lot of people are probably more likely to use tooling from brew itself to manage those, and making everything native avoids the need to bootstrap from an existing runtime.

	▲	akdev1l 3 hours ago \| parent [-]
		It can revert back to building from source under some cases and I still think even when doing binary downloads it will execute install hooks which are ruby inside the recipe I would agree with you that probably Ruby itself is probably not the bottleneck (except maybe for depsolving cuz that’s cpu bound)

▲

nozzlegear 7 hours ago | parent | prev [-]

I mean, I'm confused about it. The nanobrew homepage says this:

> nanobrew

> The fastest macOS package manager. Written in Zig.

> 3.5ms warm install time

> 7,000x faster than Homebrew · faster than echo

It presents itself as an alternative to Homebrew.

▲

halapro 7 hours ago | parent | next [-]

There are many such examples for npm as well: many "compatible" managers, one registry.

▲

nozzlegear 6 hours ago | parent [-]

Sorry, examples of what? Package managers that present themselves as replacements for other package managers? Or package managers that aren't compatible with the registry they're supposed to be compatible with? Your use of scare quotes is confusing.

	▲	0x457 5 hours ago \| parent [-]
		pnmp, npm, yard all have different lockfiles, all use the same registry format (and the same registry itself), all try to stay compatible in other ways. You won't be having situation where one uses yarn and someone uses pnpm on the same project tho.

▲

7 hours ago | parent | prev [-]

[deleted]