Part II in moving to a Windows-esque development environment
If you’re new to this series, please Check out Part I here , where I talk through some of my motivations and discoveries in moving away from Apple products for development work.
Once I had settled on the hardware, I was pretty excited to start messing around with the Windows Subsystem for Linux (occasionally referred to in this post as the WSL).
Getting it set up was a breeze, although I was a little underwhelmed by the offerings
I think these distros make sense though, especially for the less experienced linux user, or maybe those of us who are decidedly not masochists. I cut my teeth building Gentoo kernels; being restricted by debian based systems doesn’t feel awesome, but I think for most folks it is a better experience.
I settled on Debian initially, and since I’m a huge Mr. Robot fan, I had to install Kali Linux as well.
Having worked a lot with straight up old virtual machines, then to containers, I was a little confused by how this thing all works when I actually got in the shell. Many times I asked myself, “Where exactly the hell am I?”
But, where…where is it? Of course, your mileage varies sometimes, depending on where you actually fire up your shell…
This was the result when I fired up my console in ConEmu, a really nice terminal emulator for windows. But, seriously. Where the hell is this exactly?
It starts to make sense if you try to traverse up to root:
I’m a little slow on the uptake sometimes folks, so I decided I’d try an experiment. I created a file in my home directory and then using the file explorer, I took a look around:
Uh, ok, sure. That makes…sense.
Clearly the Windows 10 treats your linux subsystem like any old application, which is pretty nifty, but not exactly intuitive when you start with as many assumptions as I do about things.
So there you go, you can see how things start to get a little funky, especially when you need to start developing with this beast. But if you can keep in the back of your mind that this is, for all intents and purposes, an regular old Windows 10 application installed in the store, then you can usually figure your way around things.
Obviously there is a ton more going on here, and I hate to minimize the work done by the WSL team, but hey, kudos to them for allowing me to think of a subsystem in this way. Nice work y’all.
I’m working on a few little side projects here and there, so I figured a fun way to start would be to get my go environment running with the bash system and see how I could get everything to work.
Initially, I tried installing Go on the Debian system, but I didn’t have a lot of luck with that. There were frankly, a lot of issues, but I don’t think they are insurmountable. Rather, I think my process speaks to a bit more of my laziness over my need to get Go working in my Debian environment.
There were more than a few red herrings along the way, which is to be expected. I love using the Goland IDE for development work. Recently I’ve been a bit of a convert to JetBrains and their superior product offering, especially when I’m dealing with gnarly debugging sessions and the like. As an aside, the Elixir IntelliJ Plugin has saved me a lot of time in my day to day work, and I can’t recommend it enough.
But, before I went down that road, I attempted to get Visual Studio Code to play nicely with my new bash environment.
After installing it, and adding it to my path, something nifty that happened was I was able to open projects using
$ code <project_name> very easily. Of course, this was before I realized that my WSL wasn’t actually being treated by Windows as an external vm, container, or whatever. Still not absolutely sure how this black magic works, but it makes windows tooling really seamless around the WSL.
After a lot of internet research, I learned you can point VS Code’s integrated shell to
That’s pretty darn cool, and it works like a charm.
Cool, so now I’ll install be able to install all my nifty go tools in my debian environment and go to town right? Er, wait, but the tools need to be installed in my windows system, on my $GOPATH, for VS Code to know about them right? Or am I just over thinking this?
I knew running my go environment in debian, then trying to bridge it to windows, then trying to set this up in visual studio code, wasn’t going to work without some serious thinkin on my part.
In hindsight, I could have pushed my environment variables to point to the Go installation on my WSL, but what I settled on was just installing Go on Windows and using it that way.
As you can see here, I also aliased my windows docker installation in my
bash_aliases file since I figured that would be easier as well. I’m not totally certain this is “correct”, but I have been able to run my little project in docker, from my bash terminal, using this setup:
Neato, and even
docker-compose works like a charm too:
I enjoyed an evening of hacking away when everything finally clicked.
I usually spend most of my time working on server side code, I’m not a big time front end developer, so I’m hoping the experience will be the same if not similar. I set up a similar configuration for Java, but I haven’t done much in configuration for other environments I work in, namely Elixir or Ruby. I’m curious to see how that works so I’ll continue to update with my findings.
I’ve read in my internet digging that front end work isn’t terrible on the WSL. I have a react project I’m working on currently, so I’m excited to give it a shot.
I’d say that my biggest challenges with understanding this is my complete and total unfamiliarity with the WSL and having exactly zero context about how it actually works. This is probably more a testament to my inability to read a manual and start messing around with things. I’m certain those of you out there who are smarter than I will have a much easier time grasping the design decisions and implications, so take my ramblings with a grain of salt.
As for Windows 10, I am actually really impressed with it as an operating system overall. Package management is pretty darn good with chocolatey, Docker for windows is solid, even setting up Go and Java wasn’t the worst experience I’ve had.
The bottom line is, if you’re approaching an endeavor like this without an open mind, you’re going to have a really bad time. I don’t think it’s fair to compare macOS to Windows and vice versa. Use the tool that works best for you, that helps you to be the most creative, efficient, and allows you to write the best code.
But if you are going to be in a dual environment, don’t forget about those line endings…
If you’re interested in what I’m up to, check out my github, or shoot me an email at: micah at acyclic bits dot com