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.

What are you doing that requires kernel specific code? Shouldn't you just be using cross platform libraries?

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.

Devs on Unix are by the far the worst when it comes to writing cross platform code.

This is written in go! How isn't it cross platform?!

Maybe if windows were free to use, folks who are volunteering their time and energy would be more prone to support it. Alas...

Macos is free to use?

Is this type of response called for?

Please be a good netizen.

If you’re interested in the project and are a Windows user, contribute to the project.

I can see your point, pretty aggravating. Is WSL an option?

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.

Great stuff, thanks for this great addition to the build ecosystem