When I started using a Mac in 2009, MacPorts, Fink (and I think there was another I can't recall the name) simply wouldn't work for me. They would take very long to build what I wanted, there weren't nearly as many packages as was in Debian/Ubuntu, and many were old versions. Worse, many build attempts would just fail.

In that scenario, brew worked like a charm. It was quick, had most or even more packages than Debian/Ubuntu and they were newer. Failure to install was rare.

Then, Apple started yearly release of OS X, and that both broke brew and my system hard, so I started investigating and found out about the many "shortcuts" that brew took and how it violated systems components. I was dismayed, and abandoned brew for good.

So, I stood a period where I would use many of my tools inside a Ubuntu VM, until probably 2013-2014, when for some reason I tried again MacPorts, and I don't know why, but that time it was much more reliable, and because of Apple's insane atm SSDs with 2 GB/s bandwidth, install became quick enough. Packages were still somewhat lagging behind in available versions, but the variety of them kinda reached the levels of what was in Debian/Ubuntu, so it was good enough for me.

Then, the killer feature, I found out about macports variants and selectors, which I find the most awesome thing to this date in package managers (I haven't tried nix, still, it might be magnitude better in that regard). No needing to use rvm, pyenv, custom installs of gcc messing with make/autotools, and the only sane way of compiling various Haskell projects (before haskell-stack).

MacPorts was slower (bringing in its own dependencies for everything meant longer build steps) and required sudo more. There were some annoying fiddly parts that made it seem like the homebrew users around you were having more fun exploring packages.

It was also exciting how many packages and casks were in homebrew and it was easy to make your own.

Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.

Then so many projects started to publish brew install links as a way to get started; homebrew felt like a default.

Now, with our faster computers, more space, and more packages installed, and macports shipping more binaries and using its own normal user, macports' duplication of dependencies looks more like an advantage than a disadvantage. And because homebrew taught so many people how to use package managers, macports is not their first so easier to start using.

Here's my guess.

Homebrew had at least these things going for it:

  - it has always had a strong emphasis on presenting a simple, clean, pleasant, pretty, playful UI and executed that well
  - when it came out, source-based package managers for macOS generally didn't have any binary caching mechanisms, so compile time mattered
    - Homebrew's embrace of the base system as opposed to bringing its own dependencies bought it greater reuse at the cost of robustness, driving down total time to install many packages
  - the language that `brew` and its packages were written in was trendy at thw time as well as pre-installed on macOS, which made them instantly accessible to huge numbers of web developers
    - the older macOS package managers generally drew on traditions and tooling from the Linux world (e.g., Fink, with Debian tooling) or the wider Unix world (e.g., MacPorts and various *BSD ports systems and packages written in some Tcl IIRC).

The type of person with the experience that would lead them to prefer tools and conventions like one sees in Fink, MacPorts, and Pkgsrc, or to contribute to those projects, has likely always been dismayed, if not repulsed, by a number of Homebrewisms. I think we can therefore conclude that Homebrew didn't win the package availability race by converting MacPorts contributors— Homebrew succeeded in attracting a largely untapped pool of new contributors. Eventually there followed the majority of non-contributor users who just want to use whatever already offers the software they want to run.

At the point I switched from MacPorts to Homebrew, homebrew just worked more reliably in my experience. It installed things quicker and with fewer build/install failures. i don't know enough about what was going on under the hood to have any theory as to why this was my experience; I don't want to know what's going on under the hood, I just want to type `install whatever`, and have it work.

I guess MacPorts was (and is) geared more towards users with some proper UNIX or BSD background, e.g. people coming from FreeBSD.

Whereas Homebrew targets the typical Mac user who might need a CLI application occasionally, i.e. someone looking for simplicity, without being too technically savvy.

The latter group certainly makes up a much bigger share of users on macOS, especially nowadays.

Here’s why I switched early on in homebrew’s life from ports

- brew had and has many more packages available

- brew updates versions more quickly

- brew uses much more simple paths that fit my brain better

- brew has a pleasing simplicity

When you installed a port with macports the idea was to use as much of the macports for build and runtime dependencies. Over time that became greater and so port install would be slow until you built enough dependancies. It also consumed more storage.

When you installed a port with brew it used as much of the OSX, X11, and XCode installed utilities as possible so it was faster and used less storage. But then you would install an update from Apple and things would break cause of that reliance, things like /usr/bin/perl.

People like beer but also Homebrew had a cute site and made ports simpler than MacPorts. Turns out complexity was maybe not unwarranted. I was among first adopters of brew but now I port for years

this was a while back, in the Gentoo Linux heyday, so it was popular to compile things, except that this was when computers were slow, so that meant waiting for compiles. the problem with macports was that (iirc, it's been a while) it compiled its own version of Python instead of just using the system python, which also broke sometimes. and then you had to compile all that shit again. brew won out because it was faster, and didn't duplicate redundant shit for no perceived reasom.

Same here.