[chjohasbrouck]

> it's a different system from the server, lots of tricks are needed to make it work invisibly (either with a VM or a lighter equivalent)

I used to use Linux for this reason, but it's no longer a factor in my opinion.

Ideally your development environment should mirror the production environment, and just saying "the server is running Ubuntu Server 14.04LTS and I'm running Ubuntu 14.04LTS" is a pretty lazy and incomplete way of half-achieving that goal. What about your nginx config? What about your permissions? What about your PostgreSQL version?

Whether you run Mac or Linux, you're still forced to solve that problem, and the best tools to do it are all available and work great on a Mac. Vagrant is relatively painless and works really well.

[equalarrow]

Hmm, I've never worked at a company where this was a requirement. In fact, I've worked at companies where the majority of the time, the developer environments never came close to the production environments.

What has mattered most is that a staging env mirror the prod env. This I have experienced and built numerous times. Also, an integration env between development and staging has also been fairly common.

[danudey]

Another philosophy I've always had: always writing for one system means you end up making platform-specific assumptions, even in higher-level languages. For example, concatenating file paths with / by doing "{}/{}/{}".format(var1,var2,var3) rather than using os.path.join(var1,var2,var3) and letting the system handle it.

Developing on one platform and deploying on another means you find more little incompatibilities, and can expose a lot of bugs that failed silently or did the wrong thing on one OS but broke visibly on another OS.