3 ms·
My experience is that Windows is a constant source of headaches if you're supporting development and builds on multiple platforms and trying not to just write e
by yamtaddle 4y ago
My experience is that Windows is a constant source of headaches if you're supporting development and builds on multiple platforms and trying not to just write every build-related thing twice, Bazel or no Bazel. Likelihood of it being a PITA goes up fast the more complex the build & tools (probably why Make did better than Bazel).
I assume it's OK if it's your only platform—though I got my programming start on Windows, with open-source languages, and distinctly recall how managing the same tools and builds got way easier and more reliable when I switched to Linux. Luckily WSL2 is getting semi-decent and can call out to Windows tools, so it's getting easier to standardize on one or another unixy scripting language for glue, even if some of your tools on Windows are native.
Part of the trouble with it, though, is that there are multiple ways to end up with some kind of linux-ish environment on it, and that all of them introduce quirks or oddities. You end up having to wrestle with stupid questions like "which copy of OpenSSH is this tool using?" It's probably less-bad if you're in a position to strictly dictate what Windows dev machines have installed on them, I suppose. Git is installed, but only with options X, Y, and Z checked, no other configurations allowed; WSL2 is installed and has packages A, B, and C installed; and so on, crucially preventing the installation of other things that might try to pile on more weirdness and unpredictability.
Those kinds of messes are possible on macOS or Linux or FreeBSD or what have you, but generally don't happen. I think it happens on Windows because every tool's trying to vendor in various Linux-compat dependencies rather than force a particular system configuration on users, or having to try to deal with whatever maybe-not-actually-compatible similar tools the user has installed. So they vendor them in to reduce friction and the rate of spurious bug reports. Basically, the authors of these tools are seeing the same problems as anyone trying to configure cross-platform development with Windows in the mix, and are throwing up their hands and vendoring in their deps, which compounds the problem for anyone trying to coordinate several such tools because there's a tendency for everything to end up with weird configurations that don't play well together.
- trzy 4y agoAll excellent points but Windows is a very widely used platform (perhaps the most widely used, by some metrics) and it’s actually quite nice for development. It’s hard to take tools seriously that don’t work on it. Unpopular opinion but I think the Unix approach of lots of little tools with arcane configuration files all blaming each other sucks. I get why it exists, why it became popular, and why it remains popular in some scenarios, but I don’t feel beholden to it.
- yamtaddle 4y agoRight—in some sense it's not really Windows' fault that something like Git is barely-portable and relies on a rube-goldberg-machine pile of scripts and binaries in several languages with the result that it has to ship half a unix environment to work somewhere that's very non-unix, or that open-source software in general treats Windows the way web developers treat Firefox. OTOH, in practice, if you're using a lot of open source tools and have developers working on every single halfway-plausible OS except windows, things are probably pretty OK, but then you throw Windows in the mix and suddenly the time you spend supporting your builds & tools shoots way up. That makes it feel like it's Windows' fault.
- cma 4y agoAndroid is an even bigger pain, suddenly you have to call Java code just to map memory and can't even have a simple C api for something as low level as that.
- yamtaddle 4y agoAs a development and/or build environment? Never used it that way, myself. Agree that as a build target, and as far as its various first-party developer-facing features and libraries and SDKs and such go, it's got weirdly-many rough edges and half-baked-but-heavily-promoted junk for such a major platform.
- hactually 4y agoGit is written in C. It hasn't been a "rube-goldberg-machine pile of scripts and binaries in several languages" for a long time (almost a decade).
- howinteresting 4y agoHas git rebase --interactive been rewritten in C yet or is it still a bunch of Perl?
- 4y ago