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.
Indeed, everyone's free to do what they want, that's the beauty of open source.
I have zero issues with people vibe coding alternative Homebrew frontends, it's good for the ecosystem for there to be more experimentation.
What I take objection to is when one or more of these happen:
- incorrect compatibility claims are made (e.g. if you're not running Ruby, no post-install blocks in formulae are gonna work)
- synthetic benchmarks are used to demonstrate speed (e.g. running `brew reinstall openssl` in a loop is not a terribly representative case, instead a e.g. cold `brew upgrade` of >10 packages would be). to be clear, I'm sure most of these projects are faster than Homebrew in fair benchmarks too!
- incorrect claims about why Homebrew is slow are made (e.g. "we do concurrent downloads and Homebrew doesn't": true a year ago, not true since 5.0.0 in November 2025)
- it's pitched as a "replacement for Homebrew" rather than "an alternative frontend for Homebrew" when it's entirely reliant on our infrastructure, maintainers, update process, API, etc.
Even on the above: of course people are free to do whatever they want! It's just at least some of the above hinders rather than helps the ecosystem and makes it harder rather than easier for us as a wider open source ecosystem to solve the problem "Homebrew is slow" (which, to be clear, it is in many cases).
Thank you for the answer now it made more clearer, at least for me, on what you meant.
And to be fair, when I was at 4.x version, 90% of the time I was in the happy path, my "being slow" issue was when download speeds got really bad, sometimes caused by my ISP, so my end.
As others mentioned, homebrew is a great piece of software, thank you, not only you but everyone who maintains it.
Thanks for all the hard work. I think brew is what makes the Mac the best “unix” machine choice as far as being stable and not having to take up maintaining my OS as a multi-hour per week hobby. I have been using it daily for three years and have never had any problems.
> People are free and probably do this because it is slow. Alternatives often are not a bad thing.
Alternatives are always good but IMO brew is just not something I interact with all that much and to me it's "good enough". It works and does what I expect, although to be fair maybe I'm on the happy path <shrug>.
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.
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.
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.
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.
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.
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)
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.
Less charitably, pacman is fast because it's wrong. The dependency resolver is wrong; it fails to find correct answers to dependency resolution problems even when correct answers are available.
* 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.
> 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?
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)
> 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?
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.
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.
> 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.)
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.
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.
> I appreciate the push for an official rust frontend
Why? I think I am seriously starting to contract as case of FOMO. I feel like Rust is rapidly gaining territory everyday. I mean, that's fine and all, I suppose. I have never used it, so I have no real opinions on the language.
Wait a minute, Homebrew is slow? I thought most of the time it takes for me is downloading and installing. I haven't noticed slowdowns anywhere else, even for the ones mentioned.
In it's current form, homebrew is amazing. It's not that slow and recent updates have made it really good to use. May I know the reasons for a Rust rewrite?
> 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”.
This is literally what "compatible" means, how else did you expect then to frame it?
That is great news! Would be even more awesome if it was being ported to a more approachable language like Go or Zig, or somehow rearchitected in Ruby, but I take it that ship has sailed long ago. Ruby -> Rust is a brutal move.
McQuaid is correct in the strict sense, but the interesting question is what percentage of actually installed formulae use Ruby DSL features beyond archive extraction and path manipulation. My guess is it's a small minority of what most developers have on their machines.
The real compatibility test isn't "runs all Homebrew formulae" — it's "runs the 15-20 formulae each developer actually uses." A tool that handles those correctly and fails clearly on edge cases is more useful in practice than a technically complete implementation that's slower.
What's missing from this thread is any data on that surface area, not more benchmark numbers.
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.
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)
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.
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.
> Homebrew is working on an official Rust frontend that will actually have full compatibility. Hopefully this will help share effort across the wider ecosystem.
Homebrew's most significant changes since 5.0.0 are expanded `brew bundle` support, `brew version-install`, new `-full` formula handling and installer updates.
Means a lot coming from you - thanks for taking the time to post, and for taking the time to make the Homebrew formula. (I am also a fan of the author's (webcoyote's) other work.)
If multiple people are assuming bad faith: perhaps you should adjust your communication in future rather than trying to change their mind. An apology wouldn’t hurt, either.
It’s not “multiple people”, I asked that of one person multiple times.
And respectfully Mike, you’re not the person to be schooling others on respectful communication and requesting apologies. You are incredibly abrasive, often rude, and the reason many people avoid Homebrew altogether. You’re repeatedly criticised for “being a dick” or an “asshole” (I personally would use neither), including on HN submissions. You are very far from the paragon you are exalting.
I used to defend you when I contributed more regularly to Homebrew, but as time went on I now only ever find you in contexts of trading insults and never giving an inch or admitting wrongdoing. Even when it seems you are, you always find a way to end with some subtle jab at the other person.
For sure I could do better. I try and often fail, and that’s how we grow. But it is profoundly hypocritical of you to act like you are an example.
No shade on most other Homebrew maintainers, though, and thank you nonetheless for all the work you do.
You will find many examples of me apologising and changing on Homebrew’s issue tracker, they just tend to not be the cases that people decide to bring up here. It’s unsurprising to me that 16 years of working on Homebrew most days has a bunch of suboptimal communication in that time. I am not perfect but also never claimed to be.
Attacking my communication here doesn’t help you. I got involved in this thread after seeing someone saying they regret sharing this (interesting) project from your reaction and feeling the same way after your reaction to something I’ve shared. Feel free to ignore me as is your right.
Ignoring the specifics, your first paragraph applies to me. You simply decided to assume it doesn’t and stoke a fire which, as far as I was concerned, was already out.
Please don’t do that. It’s not the first time I see it. You come in, say what you want, then leave and say “you can ignore it”. So can you! You could’ve ignored it. I guarantee you that the overwhelming majority of times you do that, you’ll just make the other person mad and the situation worse. If you want to do better, and I believe you do, those backhanded dismissals need to stop.
I did not reread the whole thread before replying and should have done that at which point I would have seen your apology. I apologise for not doing that. Good on you for apologising. I will ignore more in future.
Don’t. It’s a cool idea and vibe coding it doesn’t make it less interesting. You don’t owe anyone anything and the mean behaviour you’re in receipt of says more about them than you.
There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way.
In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on an already made decision doesn't help anyone. We have a discussions forum (and, well, the rest of the internet) for discussion of the pros and cons of decisions made. There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
Go read through some merged pull requests some time and you will see moderately to very positive responses from me. That's because that's the work that keeps the project alive. It has almost died several times in the past and I've kept it going. You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
Thanks for the response. Yes, I think some clarity about the purpose of the issue tracker would help someone unfamiliar with the project's maintenance better understand the conduct of the maintainers. If it is only for coordination of work tasks and not discussion of whether the work should be done, it would seem natural to have somewhere else where the discussion of the merits occurs.
> drive-by negativity by non-code-contributor users is the biggest existential threat
I do believe this, and it's what I was getting at with my "conditions a knee-jerk asshole response" comment. From the outside, I saw someone who wasn't being negative, but just seemed to have unaddressed concerns about the impact of the change. You, however, have been conditioned by hostile users over your many years of work to interpret this as negativity, because other, ruder people pile on to the valid concern in unhelpful ways, or the person with the concern wasn't willing to listen at all and just used a veneer of calm rationality to be a stick in the mud.
The point is, I get why you would be this way, but also that it doesn't look very good from the outside looking in. I know that you are doing unpaid labor and so nothing is owed, but still, both can be true.
I know some people don't like it, but I've always found discussions that are locked to collaborators only to be totally understandable for this reason. If you find yourself making "I know more about x than you ever will" comments to a person, you should probably instead just disregard them and carry on. Likewise, you do know more about x than I ever will, so you should probably just disregard me and carry on.
> There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
You could have just said this (maybe you did when linking the code of conduct) instead of writing a paragraph of confrontational arguments and it would have looked way better imho.
> You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
Yup, you're right, I should have. We will adjust the CONTRIBUTING.md accordingly.
> If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
I didn't say every OSS project, I said projects like Homebrew. I know that Homebrew would be dead without many of my personal interventions. You can believe me or not but, unless you're a Homebrew maintainer, it's unlikely your opinion about what happens behind the scenes is informed.
> As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.
I don't think I am a dick, I guess that went without saying.
I'll take critique from other maintainers who have done as much or more open source work for similar returns over similar time periods. Funnily enough, I'm friends with many, and they are supportive the vast majority of the time instead of critical. Maybe that's because they can relate and you cannot.
No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.
The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)
If you love Homebrew, maybe you might want to consider if repeatedly calling me a dick or arrogant/blunt is a particularly nice way to treat someone who spends their spare time building software you rely on.
This, this is being a dick. Holding your project hostage because you want to flex your power over someone. It's entitled behavior. Glad I moved to MacPorts years ago.
As an open-source developer, is there a way to have my apps pass Gatekeeper without paying the $100/year Apple ransom and notarizing them? I think it’s the crux of the problem.
As I’m writing these lines, Homebrew has 7656 casks in the official cask tap[1]. I’m not sure exactly how many of those are unsigned but if we assume 4000 then signing them all would be an additional $400,000/year extorted by Apple from the open-source community.
Defining HOMEBREW_CASK_OPTS=--no-quarantine in my shell configuration was a good way to avoid this issue without having to manually run dozens of xattr -d every time I run brew upgrade.
Now my only option left is to pull the trigger and make my system globally less secure: sudo spctl --master-disable
Unfortunately, disabling Gatekeeper doesn’t just allow unsigned apps to run: it also completely disable all verifications for signed apps: notarization checks, revocation checks, trust evaluation checks.
I’m worried app maintainers will start to indiscriminately run xattr -d no matter if the user actually wants that or not. There will not be any kind of standard way to do that so the experience will be very inconsistent between casks…
I hope Homebrew will start supporting hooks at a later point because it would allow users to automatically de-quarantine instead of having all maintainers add xattr -d garbage commands to all their casks.
Yes, active support dropped for macOS Intel September 26, won’t work at all on macOS Intel September 27.
We’d love to support everything indefinitely but lack the resources as a volunteer run open source project to do so, particularly when GitHub Actions and macOS itself will be stopping elements of their support for macOS Intel on similar timescales.
No(t yet). It's a slimmer version of the existing JSON API that's similarly only used by homebrew/core and homebrew/cask for now, mainly because they are so huge that using Git for this had very poor performance.
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.
reply