6 ms·

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 Homebr

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.

pxc 7mo ago
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 7mo ago
  Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon
  - petcat 7mo ago
    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.
    - novok 7mo ago
      Ruby doesn't have to be the slow part, bazel uses starlark which is mostly python and it's very fast.
      - SlightlyLeftPad 7mo ago
        Bazel has other problems
        ukuina 7mo ago
        Could you elaborate?
        SlightlyLeftPad 7mo ago
        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.
    - kelvie 7mo ago
      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 7mo ago
        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.
        pxc 7mo ago
        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.
    - akdev1l 7mo ago
      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 7mo ago
        > 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 7mo ago
        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 7mo ago
      > 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?
      - what 7mo ago
        This. There are much better reasons to abandon brew than “it’s slow”.
  - pxc 7mo ago
    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.
  - joemi 7mo ago
    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.
    - SlightlyLeftPad 7mo ago
      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.
atonse 7mo ago
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 7mo ago
  I think Max Howell created Homebrew. I think McQuaid is the current maintainer
  - mikemcquaid 7mo ago
    Correct. Max created it in 2009. I joined a few months later. I've only maintained it for 17 years.
tfrancisl 7mo ago
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.
- hirvi74 7mo ago
  > 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.
boobsbr 7mo ago
Please, don't remove bottles and casks that are blocked by Gatekeeper. :˜(
- forsakenharmony 7mo ago
  I also think it's a bit unfortunate, but I can also see the side of not wanting to support things that technically make macos less secure
halapro 7mo ago
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.
- nozzlegear 7mo ago
  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.
  - deleted 7mo ago
    [deleted]
  - halapro 7mo ago
    There are many such examples for npm as well: many "compatible" managers, one registry.
    - nozzlegear 7mo ago
      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 7mo ago
        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.
- akdev1l 7mo ago
  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
orf 7mo ago
https://github.com/Homebrew/brew/tree/main/Library/Homebrew/rust/brew-rs https://github.com/Homebrew/brew/tree/main/Library/Homebrew/... for reference
runjake 7mo ago
Context for those unaware: the commenter, mikemcquaid, is the project lead for Homebrew.
- Xunjin 7mo ago
  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.
  - huflungdung 7mo ago
    [dead]
  - runjake 7mo ago
    Point noted! I took it as a tongue-in-cheek phrasing of "agentically coded". Hopefully, that's right.
  - alwillis 7mo ago
    Since I enabled HOMEBREW_DOWNLOAD_CONCURRENCY, downloads have improved for me to the point where download speed is no longer an issue.
    - brailsafe 7mo ago
      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.
    - firecall 7mo ago
      If your version is 5.0.0 or newer, concurrency is already active by default. https://brew.sh/2025/11/12/homebrew-5.0.0/ https://brew.sh/2025/11/12/homebrew-5.0.0/
      - 7mo ago
derefr 7mo ago
> 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.)
- mikemcquaid 7mo ago
  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.
yokoprime 7mo ago
thank you for all you (and your co-maintainers) do for the community!
hirvi74 7mo ago
What drove the choice to use Rust for an official frontend?
AbanoubRodolf 7mo ago
[flagged]
waterTanuki 7mo ago
> 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?
cromka 7mo ago
> 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?
- ricardobeat 7mo ago
  It’s more of an alternative CLI for Homebrew itself, not an alternative that happens to be compatible.
breppp 7mo ago
I think you are doing great work with brew and I hope the Rust version is released soon However, how is this effort different than uv vs pypi? why is this a bad thing?
ricardobeat 7mo ago
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.
anbotero 7mo ago
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.
adityamwagh 7mo ago
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?
patabyte 7mo ago
I'm really interested to learn more about the work on the official Rust frontend - do you have any links to share by chance?

pxc 7mo ago

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 7mo ago
Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon
- petcat 7mo ago
  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.
  - novok 7mo ago
    Ruby doesn't have to be the slow part, bazel uses starlark which is mostly python and it's very fast.
    - SlightlyLeftPad 7mo ago
      Bazel has other problems
      - ukuina 7mo ago
        Could you elaborate?
        SlightlyLeftPad 7mo ago
        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.
  - kelvie 7mo ago
    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 7mo ago
      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.
      - pxc 7mo ago
        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.
  - akdev1l 7mo ago
    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 7mo ago
      > 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 7mo ago
        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 7mo ago
    > 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?
    - what 7mo ago
      This. There are much better reasons to abandon brew than “it’s slow”.
- pxc 7mo ago
  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.
- joemi 7mo ago
  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.
  - SlightlyLeftPad 7mo ago
    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.

atonse 7mo ago

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 7mo ago
I think Max Howell created Homebrew. I think McQuaid is the current maintainer
- mikemcquaid 7mo ago
  Correct. Max created it in 2009. I joined a few months later. I've only maintained it for 17 years.

tfrancisl 7mo ago

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.

hirvi74 7mo ago
> 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.

boobsbr 7mo ago

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

forsakenharmony 7mo ago
I also think it's a bit unfortunate, but I can also see the side of not wanting to support things that technically make macos less secure

halapro 7mo ago

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.

nozzlegear 7mo ago
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.
- deleted 7mo ago
  [deleted]
- halapro 7mo ago
  There are many such examples for npm as well: many "compatible" managers, one registry.
  - nozzlegear 7mo ago
    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 7mo ago
      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.
akdev1l 7mo ago
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

orf 7mo ago

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

runjake 7mo ago

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

Xunjin 7mo ago
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.
- huflungdung 7mo ago
  [dead]
- runjake 7mo ago
  Point noted! I took it as a tongue-in-cheek phrasing of "agentically coded". Hopefully, that's right.
- alwillis 7mo ago
  Since I enabled HOMEBREW_DOWNLOAD_CONCURRENCY, downloads have improved for me to the point where download speed is no longer an issue.
  - brailsafe 7mo ago
    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.
  - firecall 7mo ago
    If your version is 5.0.0 or newer, concurrency is already active by default. https://brew.sh/2025/11/12/homebrew-5.0.0/ https://brew.sh/2025/11/12/homebrew-5.0.0/
    - 7mo ago

derefr 7mo ago

> 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.)

mikemcquaid 7mo ago
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.

yokoprime 7mo ago

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

hirvi74 7mo ago

What drove the choice to use Rust for an official frontend?

AbanoubRodolf 7mo ago

[flagged]

waterTanuki 7mo ago

> 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?

cromka 7mo ago

> 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?

ricardobeat 7mo ago
It’s more of an alternative CLI for Homebrew itself, not an alternative that happens to be compatible.

breppp 7mo ago

I think you are doing great work with brew and I hope the Rust version is released soon However, how is this effort different than uv vs pypi? why is this a bad thing?

ricardobeat 7mo ago

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.

anbotero 7mo ago

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.

adityamwagh 7mo ago

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?

patabyte 7mo ago

I'm really interested to learn more about the work on the official Rust frontend - do you have any links to share by chance?