but also WSL2 doesn't add anything of value to the development experience on Windows that wasn't already possible with a VM.

For my use cases, I just want to target unix-like APIs and use bash-isms so I can reuse my build scripts and tooling. I don't really care if the binary format I consume or compile to is different to Linux - as long as my development experience is identical across MacOS, Windows and Linux.

A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need.

The closest I've come is using Msys2 with zsh and uutils and it is so close but there are still cases where it simply doesn't work. WSL1 was pretty close but it falls short by needing remote development tools and having isolated storage/poor performance interacting with host storage.

WSL2 is DOA for me, I just hand roll my own Linux VM and call it a day.

The thinness is actually part of the problem. POSIX and Windows APIs don't work like each other.

For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead.

So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally.

See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8

I do think that talk is way too kind to the windows design. they're trying to make the argument that windows filesystem isn't slow, but the talk is how fixing the problem took 3 months of optimization and direct help from Microsoft. all of this could be avoided if Microsoft made their filesystem not ridiculously slow

NTFS/ReFS are not slow. But there is an extensible file system filter layer above them that can slow things down.

microsoft introduced Dev drives for this reason, they are optimized such that no file system filters are attached

https://learn.microsoft.com/en-us/windows/dev-drive/

I thought by filters they quite literally mean the antivirus filters in Defender? Does it strip down some of the Windows file semantics too?

File system filters are pluggable kernel drivers. For example, ProcMon (Sysinternals tool) monitors file systems via a file system filter -- so fun fact, if you outright disable file system filters on a ReFS volume, you won't get any ProcMon results! This was a 'duh' moment for me.

https://learn.microsoft.com/en-us/windows-hardware/drivers/i...

I find the filesystem and network integration to be a lot nicer than I what I get from a Virtualbox VM. Having the WSL system able to see the host as /mnt/c and also have the WSL filesystems appear in Windows Explorer is pretty darn convenient.

I know conventional VMs do this kind of thing too, but I've always found it more awkward to set it up, you have to install special tools or kernel modules, etc. With WSL it just works out of the box.

WSL2 supports all the good stuff like systemd. With WSL1 I'd have to rely on Windows utilities or handroll a lot more things

> WSL2 supports all the good stuff like systemd.

That has to be sarcasm, right?

Then again, I see WSL as a poor man's Linux ("poor man" being a developer in some enterprise who can't pick their tools freely due to some IT policy).

I like systemd. But I only know and use it superficially, mainly for fairly simple units that are sometimes running on a schedule.

And while WSL is worse than Linux without Windows, I still prefer it over MacOS with Linux running in a VM.

I felt the same way. WSL1 was game changing, while WSL2 isn't much better than just running my own VM, and in some ways is worse.

The one exception: my God filesystem performance on WSL1 was ass, and not an easy problem to fix

> A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need.

Something like skeeto's w64devkit? https://github.com/skeeto/w64devkit

For a subset of "run shell scripts", I'm a fan of the one-executable-file busybox for windows.

pulling up terminal running WSL instead of running a VM is a superior experience to me when all I need is terminal coding and python/bash scripting without having to block off a chunk of RAM for a virtual machine