I have the same problems as most people: it's a separate subsystem, which means you either need special integration or simply can't do what you want to do. The filesystems aren't the same, the devices aren't the same, the networking isn't the same, and all three are pretty much needed for daily work.

I suspect that most things that you can do in mingw64 will work the same in WSL, but things you need to do beyond that are basically broken in WSL and sub-optimal in mingw and almost always gets you to a point where you need a VM.

At the same time WSL has super limited benefit if you don't need any of the windows stuff, it basically means you are using linux inside windows but not using windows. When you use 'shell oriented workflows' on macOS, it just works, be it with BSD vs. GNU diffrences, which are easy to overcome by either learning or installing GNU versions of the tools you want (using a package manager like brew). In this setup, everything is the same system, what you do in the GUI also exists in the CLI, they interact directly with eachother, maintain state equally well, integrate directly with the rest of the OS, and basically has desktop functionality that isn't in the way of your development capabilities.

The only downside you can expect is if you need native windows development or windows-only tools, for everything else, windows doesn't really count anymore in almost all environments where I work (which is mostly retail, ecommerce, FOSS, infra). Only a small subset of things (large in quantity, small in configurations/versions/specific needs) that are managed by MSP's are still embedded windows or enterprise windows.

We do have a few people that actually like windows (be it the GUI, long time experience or simply brand affinity), but that's about it.

Can you provide some examples? I've used the fs and networking without issue, so I'm wondering where you hit issues. I can host a server in WSL and hit it from windows via localhost. I can download a repo in windows and access it from emacs, I can download a repo using Linux git into a windows file system and edit it from either OS. Is it that some parts of Berkley sockets aren't implemented fully (or weren't last time I took it for a spin last year)?

IO performance is atrocious. git status on a Linux tree takes a 10s of seconds.

I don't know when you last tried it, but IO performance is much better in the new (Fall Creators Update) version. I had the same problem with git status but after updating it's much quicker. Things also seem like they're faster in the WSL file system than when you're using WSL in the Win32 file system.

It is much better (and even better if you disable Windows Defender on your WSL stuff), but it's still not nearly as fast as actual Linux. I switched from WSL to a Linux VM primarily due to IO still being slow enough to be a problem for me.

Git works perfectly in PS, why would you need to run it in WSL?

Not the original commenter, but I do everything else in bash, and zero things in PS. Why would I want to remember which shell runs which program best?

I don't think that is correct. If you install WSL you are not a typical Windows user.

I didn't mention "typical" Windows user. WSL will always be a second-class citizen in Windows, so if you are power user trying to improve your performance, what's the point in choosing a second-class solution after choosing this OS? Learning one more shell, just like learning one more programming language, has some benefits.

Because I like Windows for myself but my company uses Linux based servers and bash as our shell. It's not just about ME switching to PowerShell, but getting 30 other people to do it too. Not gonna happen.

Because compiling the Linux kernel doesn't? And well, that's another big thing with WSL, you can't share files.

I periodically boot into Windows 10, mainly for join.me calls with customers, and I'm always curious to see how the WSL is progressing. It's clearly come a long ways, and I'm encouraged by the recent support for multiple Linux distributions. But for development purposes, it's doesn't yet come close to replacing a native Linux environment.

The performance is frankly terrible by comparison -- for example, running `bundle install` in a moderately complex Rails application will take nearly an order of magnitude longer (not to mention the Windows virus scan process soaking up 30% of your CPU the entire time).

Another issue is with background services -- I've had numerous issues running PostgreSQL, Redis, and other services (e.g. some services fail to start, or cannot be cleanly stopped, or I'll encounter strange network errors). However, these issues are all documented extensively in various GitHub issues, so hopefully they'll be resolved going forward. For PostgreSQL, the usual suggestion is to install PostgreSQL in Windows, and then access it from the WSL, but that kind of defeats the purpose.

I don't mean to be overly negative, but at least for my purposes, the WSL just isn't quite there in terms of being a viable alternative for daily development work.

file corruption was the worst, incomplete apt package support second.

It says officially: don't edit ubuntu files from windows editors, so it's not their fault. But not ready for work.

I can't open files in VSCode that live in the WSL virtual file system. Which is a huge problem for setting up the same exact dev environment I have on my Mac.

It's honestly dumbfounding. VSCode works great on Mac with the existing terminal but the WSL team can't figure out a good way to allow you to edit WSL files from a normal Windows application.

The way you do this is to cd into your Windows system from within WSL. WSL can see files from the Win32 subsystem just fine.

That is not a solution. I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files.

As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.

If you want to access your home folder in both, all you have to do is first create the folder in Windows, for example, create a wslhome folder inside your user folder in windows. Copy everything in your current WSL home folder, including hidden files, into that one. Then rename your WSL home folder to back it up and replace it with a symbolic link to the Windows folder. In WSL, use ln -s /mnt/c/Users/[your Windows user name]/wslhome /home/[your wsl user name]. The real folder exists in Windows and is usable in either environment.

This is exactly right. Having interop is great.

> I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files.

No. You don't want this. Linux and Windows are different platforms; if your Windows application could use your packages installed through Linux (and vice versa) then none of the native modules would work without a reinstall.

The side effects suck and they can make it better IMO but not sharing dependencies isn't an issue at all IMO.

> As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.

Yeah that sucks though for some things like git bash, etc, they use the proper windows home directory. So I end up just keeping those there and straight up copying or aliasing them to the WSL home folder.

It's not a great experience but it works.

Of course I want this!

Globally installed npm and composer packages live in ~/.npm/ and ~/.composer/ and they both have a global packages.json esque file that I need to occasionally edit. The packages installed in those folders MUST be parsed by VSCode for intelesense to work properly.

All I'm saying is I'm not gonna jump through all these hoops. I'd rather just keep working on my mac.

Hell I'd rather hackintosh a surface pro rather than deal with these issues.

Running VSCode through X is annoying.

npm/node works fine in Windows (and I'm pretty sure it's the same with composer), so why do you want to use it in WSL?

Edit: this is a genuine question of an engineer, who uses Git/npm/node for fullstack development on Windows 10 every day. What kind of setup do you have and what UX do you expect, that requires running the tools in WSL?

I just don't want to use Windows to test my code when production is in Linux. There are things all those tools do when running in Windows that is specific to Windows. And I'm not some anti-windows Microsoft hating guy. My main desktop is running Windows 10 and I was quite excited for WSL to come out so I had Windows 10 Insider Preview running on my machine for more than a year. But at the end of the day when I want to do "real" work I keep going back to my Macbook.

Windows command prompt compared to bash is simply horrible. I personally find Powershell to be just as bad. The console app in windows is still light years behind Terminal in OS X. In fact VSCode's built in terminal wrapper is orders of magnitude better.

Things like wkhtmltopdf to generate PDFs or ffmpeg to work with videos should run as they do in Linux on the production server. In OS X I can use brew to set things up. In windows I have to hunt down binaries, put them in the right place, and set the path manually via an OS level GUI many clicks down in Advanced Settings.

The extra work I need to do to make all those tools work in windows makes setting up a windows dev environment cumbersome and annoying. The way it's laid out in OS X gives me way cleaner interoperability with the way the code actually runs in a Linux environment.

It's one of the reasons I love WSL! Finally I can have a ~/.ssh/config in Windows! But I still can't edit the file from a Windows text editor.

Finally if I'm on a team where the production environment relies on some of these linux binaries being available I don't want to waste work hours researching and writing on boarding documentation for the one dev that feels like working in windows when the rest of us are on macs.

C:\Users\Windows Username\AppData\Local\lxss\home\WSL username\.ssh ?

Unless i'm misunderstanding the issue

Stuff in lxss is treated "special" - files in that directory have unix numeric permissions on NTFS instead of ACL permissions. Windows doesn't know how to set those, so if win32 subsystem is updating permissions (for instance, on file save) and the linux subsystem is updating metadata (for instance, on file save), it's possible to end up in a state where neither subsystem is able to get permission to touch the file again.

For this reason, it is recommended to only edit files outside this directory from both subsystems (not to say this isn't issue-free, but it's relatively reliable.)

The file becomes invisible to WSL right after it gets edited in Windows. It's because it's doing weird tricks to associate UNIX permissions to files stored in Windows. The Windows app will break those permissions so instead of mitigating that in WSL it simply stops being able to "see" the file.

There's a perf hit. You may have noticed disk access in WSL outside this directory is slow. Inside this directory, wsl should be the same speed as w32 native, because it doesn't hit the magic layer.

Do you have more detail about this? I edit files in VSCode/Notepad++ and execute them in WSL daily and have never run into this issue.

Would drvfs and symlinks solve your issue with ssh and npm?

I'd install vscode in wsl and run it through a Windows X server.