We are finally entering the final part of this one-year retrospective by shifting gears into developer-oriented topics.

I hadn’t touched Windows to write code since 2006 and the development experience has massively changed for the better during the last 6 years. So let’s start this part by talking about the crown jewel of development on modern Windows: the WSL + Windows Terminal + VSCode trifecta.

For a little bit of context: if you don’t know me, I’ve spent almost all of my programming years (so far!) on Unix systems, though I do have some experience writing software for Windows: I wrote a few toys back in the day with Visual Basic 3.0 and created Boost.Process during the Google Summer of Code 2006 program to teach myself some Win32. These days I do write software “for” Windows (I work on Azure Storage after all, but that’s so infrastructure-y that barely qualifies) yet, for my personal projects, I still continue to develop code that primarily runs on Unix systems.

WSL

WSL, or Windows Subsystem for Linux, brings a real Unix-y interface to Windows (again). You can’t use this for administration tasks much, which I still think is a pity, but it’s a very useful environment to support development tasks.

In particular, WSL works very well because it is Linux, which means you can run a regular Debian system and have almost everything work out of the box. Because of this, WSL can sometimes be even more convenient than macOS, which sounded shocking to me when I said that out loud a couple of days ago: macOS is truly a Unix system underneath but, unfortunately, you have to bend over backwards to make some stuff work.

Recent versions of WSL feel even more transparent than being “just a VM” because graphical apps started within WSL seamlessly integrate with the Windows desktop. But this integration only goes so far: while I haven’t had to fight WSL to run the tools I need, I have had to fight Windows to get SSH inbound connections into WSL for example.

WSL isn’t necessary though. You can, of course, develop directly on Windows, which I occasionally do. However, I often find myself working within WSL because zsh is still more natural to me than PowerShell, because some auxiliary apps I need run more easily in WSL, and because tools like Git don’t integrate that nicely with Windows. Command-line parsing on Windows is a shit show that leaks through Unix-native programs like Git.

Windows Terminal

What would WSL be if you didn’t have a nice console to interact with it? Ugly and not worthy of a second look. That’s what it would be.

Windows Terminal brings a modern good-looking console application to Windows. The old console apps, like the Command Prompt or PowerShell, are separate from each other and weren’t visually consistent until recently. For this reason, there exist various alternative console applications—like Cmder and ConEmu—which are very powerful but, in my opinion, ugly and overly-complex. Windows Terminal, on the other hand, feels simple with its uncluttered UI supporting tabs, nice fonts, profiles, and a flat configuration file.

The one thing I don’t like about the Windows Terminal—and this starts to be a recurring theme in these series—is that launching it takes like forever: 4 seconds from a click on the taskbar to getting a PowerShell interpreter on my Surface Go 2. Compare this to launching Terminal.app on macOS or your favorite terminal emulator on a Unix system, all of which are near-instantaneous and make the command line feel like an integral part of the OS. Not so on Windows, and I’m not sure why.

VSCode

And what would WSL be if you were restricted to terminal apps or redirected X11 apps with their inconsistent non-native widgets? Not great, let me tell you. Hence VSCode. VSCode is the magical piece of this puzzle that makes WSL truly feel like a great development option.

VSCode does its magic by combining the best of the two worlds: a native, blazing-fast local editor (yes, I know, it’s Electron) that transparently accesses workspaces on remote (virtual) machines and leverages their power for builds and debugging. I have been a happy user of this editor pretty much since it came out, so my move to Windows is not why I started using it. However, these remote development features against WSL or SSH hosts are what have convinced me that it’s one of the best options out there, and is why I like my Surface Go 2 so much: even if its hardware is underpowered, I don’t have to worry about it because the real work can happen elsewhere.

That’s enough for today. Tomorrow, let’s build on this post by talking about PowerShell, which isn’t on the same level of importance as these three tools but is a major step up from cmd.exe and a necessity if you are going to use Windows for development.