I've been on HN for years now and I've never seen someone write "BULLSHIT" in all caps here.

Can we not do that?

That's fair enough. I can see how the response starts significantly more aggressive than I meant it to be as a quick response.

Trash talking laptops and OS choices seem to be a pressure point for HN users, considering how civilised discussion is normally.

Hmm, I guess the tone of the actual content wasn't abusive or inflammatory so I didn't think about it. OS flame wars are still burning.

We've just given up on OS X for developers at my workplace. There are just too many little incompatibilities. Especially around clang replacing gcc messing with our C++ code, but also different revisions of various gems - especially browser testing - that cause hiccups. And then there's setting up all the ancillary services like databases etc. - not just once, but repeatedly, and reconfiguration when the arrangement changes. We can reuse many of our actual deployment Puppet scripts for setting up developer Linux machines; not so much for Mac.

Various utility scripts need to be written more defensively to run correctly in OS X with its ancient shell and BSD tools.

Overall it's just not worth the hassle, particularly when you need to ramp up new developer machines in minimal time.

We use Vagrant and Chef to provision everything, and where possible, I like to keep my OS relatively clean- so I don't have any databases or anything installed in OS X anymore. We have a number of Vagrant and Chef scripts that will take developers from zero to fully running development environment with a simple vagrant init command followed by a few steps for hooking up whatever must be hooked up in the IDE for remote debugging where necessary. It's been fantastic, but we're mostly JVM based.

I could definitely see how clang would screw things up. I don't have experience as a C/C++ developer in OS X for anything other than personal electronics projects.

My personal and professional experience with significant development time in Java, PHP, Python, and Node has been that only Linux could do it as well, but the trade offs for daily desktop use simply aren't worth it. Being able to pump my development environments into a VM of the same flavor as the target environment has given me the best of all worlds. But I've genuinely never run into anything that just refused to work on OSX. I will say that Python and Python env are sometimes a PITA, but not any constant issues.

> I live in the command line and use a modern toolchain. Package management has no bearing on my development. mvn, npm, composer, gem, and pip all work just fine. Home brew gets you the OS packages and I've yet to run into an even remotely popular package not in a Homebrew repo somewhere.

When you're building for a managed runtime it's fine. When you're building native code not so much.

I would say that the same does apply for native code as well.

Developing native code means writing code, reading code and documentation, and interacting with the build system / debugger. Those tasks need to happen directly on the developer's workstation, but not the actual building and execution/testing of that native code.

This is better done in an environment with known state, i.e. either an isolated local or remote VM that will have the environment set up as required for production, and likely multiple different, incompatible environments, or some external hardware for many use cases of native code. Best practices and a modern toolchain would imply things like reproducible builds which you can't really have if you're building and running C or C++ code directly with whatever setup and libraries each developer has on their own workstation, no matter if they're on linux, windows or mac.

You need both a reproducible build environment and an environment that your IDE is tightly integrated with - at present IDE-VM integration isn't quite good enough for the same environment to act as both. The closer together those two environments are, the less common bugs that can't be reproduced in the dev environment will be, and such bugs are the hardest to deal with. (You still have to be capable of dealing with them - you'll get them even when running the same OS in both cases - but the lower the rate, the better).

> mvn, npm, composer, gem, and pip all work just fine

...for you.