I switched to it because it worked much better out of the box and required next to no fiddle-fucking to install tools I need, so I can spend my time doing what I'm actually paid for, and good at. I have no idea whether the alternatives improved in the intervening 10-ish years, any I have no good reason to look into it since homebrew still works.

That's great until homebrew breaks in some fucked up way (which a few years ago it used to do often), or they break a package (ditto) and you try to report that to them, and they act like insufferable little shits back (and don't fix the problem.)

It reminds me of my boss emailing gnu.org to tell them one of their mirrors was down and got a nastygram back that said "It's spelled GNU/Linux" and the mirror went unfixed.

> and the mirror went unfixed.

They don't maintain the mirrors themselves. These are maintained by third party who decide to hosts the mirrors so there is that.

They can take the mirrors out of rotation if they're not working.

In other words ‘I don’t care to learn a thing out of my bubble.’

I don't care what language Homebrew uses, it just works. When I got my M1 MacBook in 2021 I saw some of this negativity about Homebrew, and since I was doing a clean install anyway I decided to try out MacPorts. I quickly ran into problems and switched back to Homebrew and it's been smooth sailing.

What problems did you run into? I've been using MacPorts for years at this point since Homebrew can never seem to install libraries in a way that pkg-config, gcc, and ld can find them. (Yes, I'm aware there is a subcommand in brew to manually print the paths to libraries, this is still not ergonomic compared to MacPorts where I install a library and it more or less "just works" when I want to use it).

Also, Homebrew attempting to nuke /usr/local on uninstall left a quite bad taste in my mouth. I had installed MacTeX before Homebrew, and thankfully MacTeX had proper file permissions set up, so my TeX installation was left in-tact. Still scary knowing that this is just done in the background without warning (unless the operation fails with errors).

It makes a mess out of iconv because it's not compatible with the OSX bundled version. Without digging into it further it seems like the macports iconv headers and libraries shouldn't be in the default search path.

Homebrew started in 2009 so I would hope it's mature by now.

Ultimately users will go where the package maintainers are. There are more people out there willing and able to write Ruby today than Perl (Fink) or TCL (MacPorts).

I'm sure someone will start a macOS package manager based on python and yum to signal the waning days of those technologies.

MacPorts has 36k active ports. Estimates I see online for the number of Homebrew formulae are less than 5k. TCL isn’t difficult to write and most Portfiles are just a bunch of whitespace-aligned key-value pairs.

I'm secretly hoping for a makepkg / pacman-based replacement to homebrew, to have the same set of commands and package naming conventions across mac / win / linux

There was one, and you can find it here: https://github.com/orgs/archmac/repositories

But it is unmaintained (it seems its author has moved on to Nix).

Wasn't there one? I know there is Nix for macOS, though it's probably not very maintained.

The Darwin nixpkgs is actually pretty active and healthy, in my experience.

That is absolutely not true. The other available package managers would work 70% of the time on a good day. Homebrew is bulletproof on a current OS.

I switched because Macports reliably borked itself doing ordinary operations every 4-6 months, and Brew didn’t. That was like 2012 to be fair, but Brew’s never given me much trouble and the package selection is insanely good, so I’ve had no reason to look at other options since.

Its being in ruby is a strike against it, for me. I use it anyway. It’s probably my favorite package manager, all things considered, and I’ve used a lot.

People switched to it because MacPorts was constantly broken and took ages to install new packages due to compiling everything.

Homebrew built almost everything from source back when everyone was already migrating to it. Fink and MacPorts being frequently broken was really the big driver, IMO.

As for why Homebrew packages seemed to be broken less often, I can only speculate. At least one big benefit it had was being on GitHub. A lot of folks were already familiar with how to cut a PR. Not so with how to submit a Portfile patch to the MacPorts Trac.

MacPorts has provided binaries for many years at this point.

It has, but by then they'd already lost many users.

I'm sure some Ruby programmers were attracted to Homebrew because it felt more familiar than something written in a language like Tcl.

But Homebrew's fundamental tradeoff w/r/t purity was also a huge boost to installation speed at a time when most package managers for macOS still required you to build most things from source.

That and the slick, user-friendly UI were probably the biggest factors for Homebrew's success when it came out.

That's a false trip down the memory lane, nothing was "perfectly good" back then, arguably even now there are big issues with all the package managers

It works well now though—do you prefer any of the other package managers still?

I use both MacPorts and Homebrew. By and large, I prefer MacPorts (because I can pin a package and it will stay pinned, whereas Homebrew will upgrade a package if it happens to be a dependency of something else) but there are numerous packages and casks only available in Homebrew.

If I could switch entirely to MacPorts, I would.

I wonder why there aren't more "casks" for MacPorts. On my work MacBook, I've got Firefox, Google Chrome, Orbstack, and Visual Studio Code installed via brew casks, and none of them are present in the MacPorts catalog. Maybe I should step up and learn how to package things for MacPorts...

I think that, by and large, MacPorts wants to ultimately build things. I was just looking at the MacVim port and it does not have a way of downloading the Release from GitHub (as far as I can tell). It will download a precompiled binary from the MacPorts build farm, but it has Sparkle disabled, etc., so it is managed fully from MacPorts.

It would be an interesting discussion to have, as they do have some of that sort of thing (the 1Password CLI, for example), but I don’t know what the general policy would be.

I’d love to see MacPorts get more funding for build resources and to potentially add that, because the way that Homebrew works occasionally leaves things broken (`pipx` venvs are a great example).

I ended up having far less use for one, and the tools I do use come from cross-platform package managers like cpan and pip.

…Like I said, language X developers want all their tools to be written in language X, and their package systems too.