Mainly subtle differences around command line tools and the file system. There are UNIX cmdline tools collections for Windows (like busybox) running in the vanilla cmd.exe or Powershell, but they don't quite fit in (for instance the way how string escaping and cmdline argument parsing works). You can use bash in a mingw 'UNIX emulator', but then you can just as well switch to WSL. And those little things propagate and amplify upward into toolchains and workflows.

It's possible to create command line tools that work across Windows and UNIX-oids, and I appreciate this, but it's a lot of additional work (even 'cross-platform' solutions like Python don't fully wrap this stuff, even though they do their best).

> it's a lot of additional work

FWIW, I have been remarkably impressed with Rust for this. The stdlib and package ecosystem are unusually good at building abstractions that work across *nix and Windows, and so the average command line tool written in Rust usually has good Windows support.

Of course, the additional work hasn't really gone away - it's just been relegated to libraries unusually effectively :)

Sometimes the target OS for deployment matters. Obvious case I run into: a deploy broke because a developer using Windows didn't realize he had some MiXeD case file name with the wrong capital letter. The Linux OS on the production system noticed. Sometimes it's the availability of native modules. They tend to exist for Linux, because it's the target for deployment, and sometimes not for Windows.

Basic CI tests should catch those cases.

The file names yes, modules are catched at development time. "We can't use PackageX because it doesn't exist for Windows and Joe won't be able to run the project anymore." A VM first and WSL2 now solved much of those problems, which leaves us at why bothering with Windows in this kind of business tough.

As a web dev, my choice of OS influences:

* What IDEs/editors I have access to

* What image editing tools I have access to

* How easy it is to get my server’s backend running on my local machineas a dev environment

The last one is most relevant to this conversation. If I’m working on a bun-based project, not being able to run a local dev copy on Windows easily is a nontrivial obstacle.

While the final output should be the same, the development tools are not and that's really where all the subtle problems are.

One of the reason WSL exists is to solve this problem.

(assuming bun doesn't work on native windows but works under wsl)

WSL has its own pain points. It’s not the catch all solution everyone claims it to be.

You cannot install safari on Windows and Linux. If you want to support apple users, you need to get a mac.

Safari often has bugs and rendering issue which aren't present on Chromium or Firefox and need fallback.

Not Safari, but WebKit: https://build.webkit.org/

Lots of little gotchas if you don't at least do a fair amount of testing on Windows, since that's what most of your end users (usually) will be on.

Things like "www-authenticate: Negotiate" in an SSO environment, people pasting rich text into web forms, handling environments with private certificate authorities, and so on.

Windows it's painful slow to do anything.