> Anything that needs to simulate prod-ish environments for developers, will be using a VM (and if you're not, you should be) often via Vagrant.

I know this not to be the case, and I disagree that it should be. I don't see why I should have to spin up a separate kernel and init just to run my application during development. I wouldn't use a Mac for it, but I've seen people develop portable software which happens to work quite well on Mac and Linux dev boxes for Linux production boxes. There's a lot to be said for debugging on your home turf.

> I don't see why I should have to spin up a separate kernel and init just to run my application during development.

So that you know it.. you know.. works in that environment?

Edit:

additionally, using a VM (and particularly using a tool like Vagrant) means that the scripts/etc to setup a working dev environment need to be done ONCE, and then any developer can work on the project, on any host environment - you can use your windows machine, I can use my Mac, Fred can use his Linux box with whatever distro he wants. It doesn't matter: we all run vagrant and a provider (usually a VM hypervisor) (doesn't even need to be the same provider - you can use HyperV, I'll use Parallels, Fred can use VirtualBox, or heck even LXC), and the application runs exactly the same in that environment, with exactly the same setup. You can destroy your machine, walk to a band new one, clone the repo, run `vagrant up` and you'll have exactly the same dev environment as me again. Even if you don't use Linux for your prod environments, this type of setup is a must if you don't want developer productivity to sink to zero every time something happens that affects their host OS (OS updates breaking libs. New hardware. New software. New OS release. Switched machines. etc)

> There's a lot to be said for debugging on your home turf.

The whole point of tools like Vagrant is to allow you to run the application inside a VM, but work on it (i.e. write/debug the code) on your host machine.

Not to diminish your point, but there are cases where running application development is very easy on a mac, and linux comes as first and subsequent stages of the CI pipeline.

> working dev environment need to be done ONCE

good point, I personally would rather integrate everything into the development platform (i.e. front end http server would be just another npm package/middleware, but not NGINX, everything gonna end up under a load balancer anyway on prod/test).

In regard to different machines/OSes, issuing everyone a mac really takes away a lot of headache for organisation, at a relatively small (compared to engineering hours) cost.

> good point, I personally would rather integrate everything into the development platform

The problem is, that restricts you to what's available for your dev platform. How many nodejs http servers do ESI sub requests, or can parse and use the same VCL file as Varnish uses on prod?

> In regard to different machines/OSes, issuing everyone a mac really takes away a lot of headache for organisation, at a relatively small (compared to engineering hours) cost.

I mean, there are benefits to standardising your work force, but I don't really see your argument here because:

a) if you take this route, and then don't use Vagrant, you have to pay each and every one of your engineers to re-setup all their projects, whenever they need to re-clone them (failed hardware, wipe & install OS update, etc).

b) unless you buy everyone the same new mac at the same time, you don't have the same environment, and it's doubtful you all even have the same OS version.

c) I've never worked in a company where everyone was happy to use the same tools/platform for dev. Forcing people to use a platform they don't like, in favour of using an open source tool that solves the problem, sounds like making things harder than they need to be

d) not all projects are run by a company, or even by the same company. Freelancers collaborating is a thing.

> I know this not to be the case, and I disagree that it should be. I don't see why I should have to spin up a separate kernel and init just to run my application during development.

Because OS X and GNU/Linux don't have the same APIs?

As the article states, SUSE and Redhat will be available in a week or two. WSL should be able to support other distros or self-built Linux too, although I wouldn't know how to go about that.

I've been using Arch as my WSL image for about a year I think.

I used this tool to get it going : https://github.com/RoliSoft/WSL-Distribution-Switcher

Definitely agree with vagrant. Vagrant incidentally is monumentally horrible on windows as well.

I've heard that Git was (maybe is) not fantastic on Windows either (to the point it has to ship its own bundled version of Bash!?)

It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have.

There are some powershell wrappers that make it better.

> It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have.

For me, that's Windows' fault.

Not really. You could write a git client for windows that didn't have these issues.

Yes, I would call those changes workarounds for Windows' bugs (incase-sensitive filesystem, no ssh infrastructure, ...).

One of the reasons Git is slower on Windows, is that spawning processes is a lot slower than on Linux. Wouldn't you call that a bug?

No, because Windows wasn't designed to make Git fast.

It is a bug on Git side if it fails to be platform independent and requires POSIX semantics to function properly.

I wouldn't call "spawning processes isn't slow" or a fast filesystem POSIX semantics.

Windows has built on the premise of multi-threading and a filesystem with rich semantics, not as yet another UNIX clone.

It certainly doesn't have a very good filesystem though. NTFS is horrible on lots of small files due to MFT contention. Even arguing with fstool for a bit doesn't improve it. Check out 50k files on Linux/OSX: 2 mins.. check out 50k files on windows ... 14 mins.

And that's both SSD backed.

It is just that wasn't designed with that specific use case in mind.

But it was designed with file streams, user ACLs, easy integration points across office networks, extensible to virtual devices, and data safety with actual proper locking semantics in mind.

It's just crap at storing files!

It is your point of view, the enterprise among Fortune 500 companies using it as their IT backbone have another point of view.

I work for a Fortune 500 and we don't like it either.

Right, so again, I haven't used it, so I'm going on what I've read, but my understanding is that Mercurial (which is Python based) is much more Windows friendly, and I actually use Mercurial more than Git.

But still, regardless of whose "fault" it is, I couldn't imagine doing dev on a windows machine, some of which is because of the vastly different environment.

Mercurial is much nicer on windows. Git could have been the same but it targeted unix likes to start with and didn't evolve into something even remotely portable for a while.

I use fossil for my own projects. I find that agreeable on all platforms.

It does and some people use it for other purposes like vim. (I do). But now I've switched to WSL for the git part after creator's update since things just work. And some version of vim and neovim also works so for now WSL is like a piece of paradise in GUI prison. But the default Bash for WSL sucks so I use mintty for WSL.(sucks less and supports good colors)