| OK, I'm coming from Linux, but I have to say my experience has been the opposite. I have a semi-complex app I've decided to port to Windows (it's so far on Linux and MacOS and configures/debugs/tests servo motors on serial and CAN busses), and after a couple of days I've been unable to make any sane workflow work without installing three seperate half-assed copies of Linux userspace (Git for Windows w/ its bash install, cygwin and wsl2) and choco on top to install more Linux/Unix-originated stuff. It's a lot like MacOS and needing to fiddle with homebrew, except worse and you need four of them. Let me give you an example: I have a serial device connected to an SBC mini computer that I want to interface with from my dev PC, so I want to proxy that serial port over tcp to Windows and make it available as a COM port. On Linux this is trivial to do using socat, or ser2net+socat. On Windows, plenty of similar tools exist. Usually you need two of them, one to make a virtual pair of COM ports, and another one to pipe a TCP socket connection into one end of the pair. So far, so good. Except all of the utilities, drivers, etc. I've tried have just plain not worked, and I've tried a good half dozen. Often their last version is from somewhere in the 2007-2012 time frame, and something no longer works on Windows 11. I think a lot of devs of tools like this just nope'd out when Microsoft started enforcing signing and pushed the Store model harder, and moved to Linux or Mac. In the end I had to write my own thing for the COM pair and run socat in cygwin. And I've jumped through a few hoops like this. I'm sure if all you do is need a place to run npm from and the rest of your stuff is all in the browser, the OS barely matters. But for native dev, Windows feels dead and barren, and fully reliant on the Linux ecosystem to be productive at this point. It's where all the reliable and well-maintained stuff comes from, whereas Windows-native tools are a ghost town of abandoned, frequently closed-source binaries. The many years Windows couldn't make their minds up between the managed code .NET stack and native C/C++ APIs, and one was incomplete while the other bitrotted away, have really taken their toll, I think. |