Ruby on Rails on Windows is not just possible, it’s fabulous using WSL2 and VS Code – Scott Hanselman

I’ve been trying on and off to enjoy Ruby on Rails development on Windows for many years. I was doing Ruby on Windows as long as 13 years ago. There’s been many valiant efforts to make Rails on Windows a good experience. However, given that Windows 10 can run Linux with WSL (Windows Subsystem for Linux) and now Windows runs Linux at near-native speeds with an actual shipping Linux Kernel using WSL2, Ruby on Rails folks using Windows should do their work in WSL2.

Source: Ruby on Rails on Windows is not just possible, it’s fabulous using WSL2 and VS Code – Scott Hanselman

I’ve been doing Rails for about 13 years as well, and I’ve been following Scott for probably about that long. Heck, being a tech evangelist for Microsoft, it was probably him that alerted me to the fact that WSL was being put into Windows to begin with. And using it for Ruby on Rails development is precisely why I wanted it. So when it was first released in Windows 10 Insiders Edition, I hastily upgraded my gaming rig to try it out.

There were literal, show-stopping bugs that prevented doing the “normal”  kind of Rails development, where you install a Ruby version manager, then install the bundle gem, then install Rails, then bootstrap your site.

I keep wanting to say “emerge” when I mean “install.” I guess using Gentoo broke my brain, but, really, that’s what’s going on. When you’re doing this sort of thing, you’re installing software that’s dependent on your environment, which is exactly why portage was created.

I filed some bugs, and watched and waited. A couple of them were fixed pretty quickly. But then other problems became apparent, and they weren’t going to be fixed any time soon, so I gave up.

Then they announced the release of a big upgrade to the system. So I tried again. And, again, I found problems that prevented me from being able to develop with Rails. So I gave up, and stopped watching this space.

Now Microsoft has been evangelizing a total rewrite of WSL, and how they’ve made it “native,” and how this fixes compatibility problems and speed issues. But all they’ve done is make the tool a total virtualization of the environment, when the whole point of WSL was that it was not a virtualized environment!

WSL was supposed to bring “open source” development (like Rails, and Node) out of the dark ages on Windows, and make it a first-class workflow on the platform. This was easy to believe, because Microsoft was really lagging in these popular development scenarios, and it could be expected that they were motivated to create a bridge to get back on equal footing with Mac as the platform of choice for working with modern web technologies.

However, the situation on Windows is now worse than ever. It used to be such a hassle to do this kind of work on Windows that you’d install VirtualBox, create a VM, map your VM’s drive onto a Windows mount point, and run your development tools on the files in the mounted drive. Now, WSL2 is basically doing that for you, and not even giving you the courtesy of a GUI to manage the virtualization settings. I guess the positive way of looking it is that they’ve created a VirtualBox-type Linux VM with all the file-system mapping pre-configured.

It’s telling that the workflow that Scott is proposing is to use Visual Studio Code with a plugin for remote development.

Whatever. It’s a hard pass for me, dawg. If I needed this, I’d just install VirtualBox, and be explicit about what I’m doing.

As a side note, I’ve been using RubyInstaller for years now, on my work laptop, and it “just works.” I mean, sure, you’re limited to a specific version of Ruby, but I just make that my base, and “emerge” that one on my Mac and the Linux host server, and everything lines up. So my need for any sort of virtualized Linux environment on Windows has already been satisfied.