It’s an expensive platform to build tools for that interop with unix. Path differentials alone eat up days for tiny bugs.
For the longest time, people said they couldn't support Windows because there was no equiv of epoll/kqueue. False: IOCP can shim it.
-
-
Epoll and kqueue aren't even particularly similar. OSX has old-school (90s) signals, Linux has signalfd. Real apps use signals.
-
People target OSX-specific linker behavior (namespaced symbols) by accident all the time, also cargo cult Linux incantations.
-
These same people often don't bother to learn how the Windows linker work, even "people who know what they're doing"
End of conversation
New conversation -
-
-
That may be true, but it was always a garbage argument. We have event ports, there are lots of ways to support all models.
-
Right. Exactly. I'm saying that Linux+OSX=Unix is actually causing the exact confusion you were worried about.
-
I don't use UNIX to mean that. You shouldn't either. Writing portable code is not hard. Fucked if I'm going to test it on Windows though.
-
I did _so much_ interoperability work at HashiCorp (not least for Windows) that I'm prepared to say this unequivocally: Windows is harder.
-
1: I think it's hard to unravel the lived experience of "Windows is harder" which I of course agree with, and "there are fewer existing
-
2: infrastructure pieces that already support Windows", which imo is a big part of why it feels harder. I also have done a ton of interop
-
3: work, including doing the design for the Rust time stdlib and helping with the Rust nix (Unix shim) and mio libraries in the early days
-
4/4: I this it's unquestionable that the experience of supporting Windows is harder. The question to ask is why.
- 23 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.