How is this relevant, exactly? Ruby was written on and designed to run on *NIX OS's, as is most of the software commonly found in webapps, because it all runs on Linux servers. I'm sure it'd be a pain in the ass to get MS Paint to run on Debian, too.

MS paint on Linux is easy.I double click on paint.exe and it runs.

And I have WINE to thank for that layer of compatibility.

You realize it is that easy for you because it was a pain in the bottom for someone else, yes?

Isn't that the esssence of programming?

Historically, Ruby in general on Windows has not been awesome. But it's not going to matter when the Windows Subsystem for Linux hits stable in a few months. http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.htm...

I think that might be a bit too sandboxed for your needs.

It doesn't really matter anymore. It's been conventional wisdom for years to develop in a Linux VM if you have to use Windows otherwise. Unless that turns out to be more complex that the Windows Linux subsystem, I can't see VMs becoming an also-ran.

If a Linux VM is fine for deployment, well then that specific component doesn't really need or use Windows very much does it. (That all unixy things need to put in VMs on a host running Windows is a very different constraint.)

If it's important to deploy as a Windows process, then the Windows Linux subsystem is not much better than a VM. Point is, its no substitute for a (better) MSYS2/Cygwin.

I think I understand your point, and it's been a while since my MCSE expired, but unless Cygwin has improved a lot I would estimate a VM wrapped by Windows would be much easier to manage and admin.

Now if you're saying that the webapp itself would be required to be a Windows process, there's really no way around that. But as I implied elsewhere, the biggest stumbler for Rails on Windows has always been the lack of a compiler. Whether you compensate for that by installing a subsystem with that capability or by using a VM with the capability is largely a local problem to the company.

I've done that over the years and I used to answer questions on the RailsInstaller list, and yes, at times it was harder than at other times. I'm expecting it to be easier than ever thanks to Microsoft's recent announcement to support running Bash as a full-fledged citizen on Windows:

http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUs...

I think the majority of webdev tools are pretty tedious to set up on Windows without cygwin etc.

Node is a one click install on Windows, no cygwin required.

True, until you want to build native modules. Then you need Python and parts of Visual Studio

So? If I want to build native modules on Linux or OS X I still need Python and other build tools. It's not fool proof on any OS.

Flask is no problem, Django is child's play to setup.

I feel like that's because someone put a lot of time and effort into making Python's core library play nice on Windows, and Pythonistas tend to interact with the OS/network only through core library functions.

To contrast, Elixir runs on Windows. However, it may be hard to get all your projects up and running due to various baked in concerns where they were written to support Unix-like systems only.

Never had any significant issues with Java stuff, or php for that matter

I don't know how long ago you tried it last time, but recently this has got much better. You surely could find some gotchas here and there, but it's not as much frustrating as it was before.

I did until 3.2. The only real problem was native extensions, and many gem developers provided win32 bins for those things if they support win32 at all. Granted, I personally wasn't (...) God's gift to clean code, but I could certainly work with anything other people (say, on IRC) were working with and talking about.

The rails stack isn't designed for Windows, why should they waste dev cycles trying to support it? In any case, I do a fair amount of webdev on my windows gaming computer (don't want to mix work and side projects), VMs are so easy to set up that I barely install any dev tools on base os.