Hacker News new | ask | show | jobs
by Numerlor 448 days ago
I'm a dev using Windows, tried Linux multiple times for a couple of months and it always felt like it was getting in my way in daily usage.

Dev experience is usually at worst the same as Linux when you use wsl as you don't really need more than the terminal

3 comments

If all you need is the terminal than windows is definitely getting in your way, WSL is a worse experience. Plus you still have to put up with candy crush in your start menu, Cortana annoying the hell out of you, and the taskbar giving you unwanted updates on the latest news from the Kardashians.
I don't have any of that in Windows. I'm not using the home version but the preinstalled apps can be removed in a minute, I think cortana has been deprecated for a while now, and the only unwanted thing I've seen on the taskbar has been the weather that I've hidden with two clicks.

For wsl, it's just a normal VM that's integrated with Windows. Maybe it'd get in the way of I did development that needed to work closer with the hardware, but I don't at the time

You can remove them in a minute, but they'll come back. ChatGPT will pop in there when Microsoft adds it. You will get a full-screen blue "get windows ready" wizard every few days to "remind" you to log in. OneDrive will reappear on your desktop.

You can still choose most things, but they will keep asking and twist your arm as much as possible.

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.

I honestly have the opposite experience. I am guessing upu either develop on the .net platform or games.

Unix-likes are far more productive environments for what I do.

I'm mostly doing server code in Python nowadays.

From what I remember only the c/++ toolchains were a problem on windows but the couple of times I needed them they were either managed by some other build process and ran fine or I could just compile and run in wsl