excuse my ignorance, but are there any major developer tools that don't support Windows? I can only imagine some internal enterprise tooling doing this.
>Ultimately compatibility layers are good because they reduce developer workload so that developers can focus on what really matters
I don't mind them as a concept, but I personally want as few points of failure between me and my software as possible. Some software is already either overly bloated or buggy (or both) as is without wondering if there's now compatibility layer issues on top of it.
At all, or well? Because git works on Windows, but it's meaningfully slow as a result of NT and unix having very different ideas about how filesystems should work.
Semgrep is one that I use at work. Nix is another. Docker¹ is a third. Many terminal emulators support multiple operating systems, but not Windows.
Windows support also often lags for new programming languages. Golang didn't run on Windows at first. Crystal is only now starting to have full-fledged Windows support. Plus there are many tools that do run on Windows but work poorly or are extremely slow or require tons of compatibility shims, like Git and Emacs.
A lot of dev tools are Unix-first. You just probably use only a few of them if you work at a Microsoft shop.
--
Not Docker itself at this point but 99.9% of all Docker containers that anyone actually uses.
I personally have not owned a Windows computer in the last 10 years, and even then I only used it for gaming and not for development. If my code works on Windows without a compatibility layer that’s a complete miracle.
Many Windows developers similarly have little idea how Unix works and stay in the Windows development ecosystem.
Ultimately you can only fit so much in your head and I don’t have room for Windows to live in mine too. I’m sure a lot of Windows devs feel the same way about Unix.
Git on Windows is only supported by installing a whole suite of Unix tools and a shell.
Tools like ccache/sccache treat windows (well msvc) as a second class citizen.
Go, the poster child for cross-compilation shatters that illusion when you need to use CGO.
Python, I believe things have gotten better but the last time I tried getting tensorflow up and running on Windows it was a long and painful path involving third party python distributions, native toolchains and changing drivers.
Docker on Windows is a shim for the Windows Jobs API, as Microsoft decided to offer the same experience instead of coming up with their own set of tooling.
In more recent Windows versions, there are other ways to manage containers, specially after containerd support improved.
The best way to distribute builds on Windows is via incredible and their VS integration.
Cross compilation never really quite works out, unless one can have a complete set of libraries and toolset of the host OS, otherwise there will always be corner cases.
Python has been quite alright when using distributions like ActiveState Python.
Git, well one cannot expect better from a SCM designed for the Linux kernel project in first place.
The entire Ruby ecosystem has never had great Windows DX: the most recommended Windows builds of Ruby itself come from a "second-party" group because official upstream doesn't seem to care to bundle nice installers, there's a ton of papercuts on Windows in the base libraries even in APIs you don't think would be platform-dependent, and a large number of third-party libraries and apps just kind of invariantly assume that you will never try to use them on Windows.
You can. Idr if Docker Desktop supports it or not, but you can install Docker Engine for Windows and plug it into the Docker CLI and all that for sure.