It’s not just a choice. It’s also the kind of tooling the people developing the system have at their disposal.
For example, if all I have is a MacBook running macOS and Docker, how can I reasonably expect to port this to Windows? I haven’t owned a Windows machine for 10 years.
I am the author of Buildbarn, a build cluster implementation for Bazel/Pants/.... Buildbarn also doesn’t support Windows. If someone sent me high quality patches for Windows, I’d merge them for sure, but nobody has. Sorry you are ‘stupidly disappointed’ in me.
I make use of openat() and friends to safely populate and interact with build environments on disk.
I perform scanning of process tables to kill lingering processes. Go has no functions for that in its standard library. There are some third party libraries for that, but they are all of pretty poor quality. They are slow.
It's open source, if you want it, you can add support for it. Which is a lot more than what you can do for a lot of other development tools that only run on Windows and have lackluster or no support on Linux.
Also, they might just not have Windows developers or a use case for running the tool on Windows, so even if the cost of adding Windows support was zero, they'd have to go out of their way to test it. A lot of open source code might run just fine on Cygwin, but most people choose not to support Cygwin because damn near no-one uses it anyway.
Hi, one of the implementors here... Yes, WSL is an option, and I believe Please works just fine in it. Right now we don't have any CI etc set up so we can't stand behind it and say "this works", but it works in WSL as most Linux things do.
