This is the kind of statement that makes you pay the karma tax. WSL is great, I use it on a day to day basis. I also use Linux on a day to day basis. And as great as WSL is, for running Linux software on supported hardware, Linux beats WSL hands down. And I mean, of course it does, do you expect a VM to beat native? In the same way that Windows software runs better on Windows. (with a few exceptions on both sides).
Compared to Linux, WSL I/O is slow, graphics is slow and a bit janky, I sometimes get crashes, memory management is suboptimal, networking has some quirks, etc... These problems are typical of VMs as it is hard for the host and guest OS to coordinate resource use. If you have an overpowered computer with plenty of RAM, and are mostly just using the command line, and don't do anything unusual with your network, then sure it may be "better" than Linux. But the truth is that it really depends on your situation.
WSL 1 had fast IO but couldn't support all features.
WSL 2 supports all features but has famously slow IO.
Example:
1. Shell into WSL
2. Clone a repo
3. Make a bunch of changes to the repo with a program within WSL
4. Run git status (should finish in less than a second)
5. Open repo from a Windows IDE
6. Run git status. This makes windows change each file's permissions, ownership, etc... so it can access the files as git status recursively travels through every file and folder
7. Go for coffee
8. Go for lunch
9. Git status finished after 35 minutes.
10. Close IDE
11. Shell back into WSL
12. Make a change in WSL
13. Run git status from within WSL
14. Wait another 35 minutes as Windows restores each file's ownership and permissions one by one
------------------------------------
The IO overhead is so bad that Microsoft built two new products just to get around it:
1. VSCode WSL remote-client architecture.
VSCode acts as a server within WSL and a client within Windows. Connect both VSCode instances (through proxy/tunnel if needed) and the server can perform the client's File IO ops on behalf of the client rather than letting an Application on Windows try to interact with any of WSL's file systems.
2. Windows DevDrive
Basically set aside a virtual-disk/partition and set it up as a different file system (ReFS) that doesn't use Window's file permissions, ownership and doesn't decrypt then decompress on each file input, doesn't compress then encrypt each file output, and doesn't virus scan the files on usage.
TL;DR Store the files on a network drive and hope race-condition ops from both WSL and Windows don't corrupt any files.
This is the kind of statement that makes you pay the karma tax. WSL is great, I use it on a day to day basis. I also use Linux on a day to day basis. And as great as WSL is, for running Linux software on supported hardware, Linux beats WSL hands down. And I mean, of course it does, do you expect a VM to beat native? In the same way that Windows software runs better on Windows. (with a few exceptions on both sides).
Compared to Linux, WSL I/O is slow, graphics is slow and a bit janky, I sometimes get crashes, memory management is suboptimal, networking has some quirks, etc... These problems are typical of VMs as it is hard for the host and guest OS to coordinate resource use. If you have an overpowered computer with plenty of RAM, and are mostly just using the command line, and don't do anything unusual with your network, then sure it may be "better" than Linux. But the truth is that it really depends on your situation.