My problem with WSL
• Julian Simpson
In retrospect, I should have asked for a MacBook Pro when I joined my last employer. In fact, I ended up with a Windows 10 machine. This isn’t the worst thing in the world; one of my roles is to do some governance on our IT contractors, so I have an appetite for a certain amount of dogfood. Where that falls over is when I want to use WSL for non-trivial things.
I’ve used Microsoft products for a large chunk of my career. I used to own a copy of Xenix, the UNIX distribution from uh, Microsoft. I’ve used the Linux award-winning Services For Unix, from Microsoft. It’s great to see that they’ve embraced different operating systems and stopped throwing the word “viral” around. But WSL drives me nuts.
If you just want a decent SSH client and the ability to run BASH scripts, great. WSL works. If you want to run Vagrant or Docker, things get more annoying. I’ve spent more time attempting to get Vagrant working than I’ve spent installing Linux on my work computers. But you can make it work, and I’m sure the ecosystem is better than it was 18 months ago.
The end came when I started using Terraform in earnest. I wanted to run IDEA with the HashiCorp plugin. I had reasons to run Terraform in WSL. As Windows processes can’t see the WSL sandbox, then it’s easy to fall into a cycle of editing changes, pushing those to git, pulling them in the sandbox, and validating them in the WSL sandbox. That’s no way to be productive.
As far as I can see, there are 3 ways to fix this:
Install Linux or buy a Mac.
Use Vim or Emacs in your sandbox (I’m not a fan of that model)
Use the VSCode Remote WSL extension which allows to spawn WSL terminals from Visual Studo Code. A colleague of mine might go down this path, and I’ll update to see how that goes.
I chose the “Install Linux” option. My only complaint is that I still need to reboot into Windows, so context switches can be hard. I’ll be angling for a MacBook at work.