It's an OS inside an OS, you have to setup everything twice (Windows AND Linux) and file system access times always bites you one way or another (with WSL2 it's the IDE on Windows that suffers from accessing the Linux FS). Because it's in a container, localhost does not get resolved to the Windows host, so if you have stuff that's spread across both OS it's also annoying. Also has weird issues with corporate VPNs. And the other day switching to fish shell as default would just freeze the whole container with no way to debug it, WTF? Unlike a real Linux env, it's a black box, if it starts acting weird your best bet is just to trash and recreate it.
I mean, it works and gives a somewhat decent Linux CLI experience but personally I stick with MSYS2 whenever I can so I have a single env to deal with.
I didn't believe all the hate until I watched someone unfamiliar with Linux set up an empty Electron project in WSL.
After we hit the third "Linux"-bug that turned out to only happen in WSL, I suggested to maybe just install Linux in a normal VM. Clunky, yes. But at least it has a clear boundary. Unless you move something across it, everything will just work.
It works in Cygwin right now, it doesn't work on Win32 without a compatibility layer. Personally, I don't think of that as "working on Windows", but I concede that that's somewhat up to interpretation on the "on Windows" part. I'm confident that someone is going to get a MingW build working even if it's not official.
> With Go, it would have worked out of the box on all the targets Go can support.
That's absolutely disingenious. If you choose to only use the Go standard library , sure. But the same is true for Rust and even for C++. If you don't use any platform-specific APIs most languages will work on any target. Fish, however, does use platform-specific APIs and nothing about Go changes that.
unless you have to deal with OS specific APIs around process management and tty input, which is the bulk of what makes a shell challenging to implement