I use a mix of WSL2, and VMs. WSL2 has a few nice properties for some use cases: a) It comes default with some network binding magic (ok, just configuration) t

I use a mix of WSL2, and VMs. WSL2 has a few nice properties for some use cases: a) It comes default with some network binding magic (ok, just configuration) that makes your WSL env almost actually behave like localhost. I know you can configure this yourself, but it's nice out of the box. (on the other hand, sometimes is this exactly the opposite of what you want...) b) My main machine is a bit RAM constrained, and WSL2 will "magically" reclaim RAM when I close the consoles (unless I left something running...). Once again, not the biggest win, especially if you spec'd out your machine to run VMs, but still nice. I think WSL2's biggest wins are not for 'full out development'. But it's nice when you need want to jump in and poke at something quickly in Linux land. The startup time for the console/VM is fast enough (~1-2 seconds), and the cleanup is good enough I can quickly jump between, without having a VM actually hanging around all the time. I'm sure the file system integration is useful for some usecases... classic one would be if someone emails you data files or something. You download in your browser in Windows and then can access pretty seamlessly from WSL. I think I would summarize WSL's advantages as being a bunch of little quality of life advantages that are very much suited for Windows dominant workflows that periodically jump into Linux. There are all sorts of other disadvantages though - I would not recommend anyone who has a comfortable VM based workflow to ditch for WSL. An example of an uncomfortably stupid rough edge would be periodically time-desyncing: https://github.com/microsoft/WSL/issues/4149 https://github.com/microsoft/WSL/issues/4149 . I shit you not, my workaround is to manually adjust my linux time forward and back with `sudo date --set "${INCREMENT} seconds" until it gets close enough that OAuth doesn't shit itself.