It's a high quality linux-ish environment and has a huge ecosystem of developer tools. You can get almost anything that runs on linux on your MBP and you can also get a ton of things you can't get on linux that come from Apple or from enterprise companies.

It's also probably the number 1 dev environment for a ton of use cases so you get support and network efforts in the ecosystem. Are you a fullstack dev? Then OSX is for you. You have all your IDE, servers, Chrome, etc up and running very quickly.

If by 'almost anything' you mean 'some, mostly using node.js or ruby', then yes. Otherwise, no. For example, Docker has to run a Linux VM underneath to just work.

Both linux and macos have different strengths and weaknesses, and one is not a fully capable replacement of another, not even just for the cli/daemon stuff.

I'm writing this on a rMBP - and there are still reasons to ssh into a centos box.

The thing is on a MBP I can run a Linux VM, which is good enough for almost everything. The reverse is not true.

There is a ton of good software for macOS that isn't available on Linux.

Docker is an extreme example. Of course things relying on Linux-only kernel features are unlikely to run natively. You'll find plenty of compiled stuff on OSX (wkhtmltopdf, freeciv, postgres, inkscape, clojure, etc., etc.).

I know, I run postgis+mapnik on OSX. It is quite PITA to build, postgres clients usually link against wrong (system-supplied & ancient) libpq[1], everything links against wrong (system-supplied & ancient) zlib, half the things link against wrong (system-supplied & ancient; see the pattern?) sqlite, etc. Yes, it is problem with the build scripts, but I don't have an ambition to fix all the packages, and Linux packages do not have this problem. Actually, they have usable and maintained binaries just a single yum command away, so you are up and running in no time, compared to solving build env problems in OSX.

[1] - /usr/lib/libpq.dylib is especially annoying offender. Most dylibs are at least fat ones, but this one is x86_64 only. That means, when you want to build a fat binary of some libpq client, and it is being linked against system one, the build will fail. That includes building i386/fat version of postgresql itself.

So use a package manager like homebrew?

- Adobe + general creative apps

- Functional command line + command line developer tools