<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>moonchrome</author><text>&amp;gt;and it’s actually quite nice for development&lt;p&gt;If we are talking about stuff like backend web development then I&amp;#x27;d say no, it&amp;#x27;s actually a pain to work with - few people bother deploying to Windows these days, many libraries&amp;#x2F;frameworks treat it like a second class citizen, tooling doesn&amp;#x27;t translate well (or at all).&lt;p&gt;Even frontend webdev is very unixy due to node&amp;#x2F;npm and popularity of Macs in that space.&lt;p&gt;When you&amp;#x27;re talking about OpenCV, GPU related things, game dev then the situation is reversed.&lt;p&gt;So it highly depends on what you&amp;#x27;re developing.</text><parent_chain><item><author>trzy</author><text>All 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.&lt;p&gt;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.</text></item><item><author>yamtaddle</author><text>My experience is that Windows is a constant source of headaches if you&amp;#x27;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 &amp;amp; tools (probably why Make did better than Bazel).&lt;p&gt;I assume it&amp;#x27;s OK if it&amp;#x27;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 &lt;i&gt;way&lt;/i&gt; easier and more reliable when I switched to Linux. Luckily WSL2 is getting semi-decent and can call out to Windows tools, so it&amp;#x27;s getting easier to standardize on one or another unixy scripting language for glue, even if some of your tools on Windows are native.&lt;p&gt;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 &amp;quot;which copy of OpenSSH is this tool using?&amp;quot; It&amp;#x27;s probably less-bad if you&amp;#x27;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 &lt;i&gt;other&lt;/i&gt; things that might try to pile on more weirdness and unpredictability.&lt;p&gt;Those kinds of messes are &lt;i&gt;possible&lt;/i&gt; on macOS or Linux or FreeBSD or what have you, but generally don&amp;#x27;t happen. I think it happens on Windows because every tool&amp;#x27;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&amp;#x27;s a tendency for everything to end up with weird configurations that don&amp;#x27;t play well together.</text></item><item><author>trzy</author><text>Last year I tried doing a side project with a talented ex-Google buddy who insisted we set up Bazel to replace my simple Makefile. Three weeks later it still wasn’t working on my Windows box. We had a mixed Python and C++ code base and I like to use MinGW64 gcc on Windows. He blamed Windows and tried to get me to switch to Mac (no thanks, lol) and eventually he lost interest and gave up. The project went on to win an OpenCV funded competition and became the basis of a startup — good job, GNU Make!&lt;p&gt;So the answer IMHO to “when to use Bazel” is “never” :)</text></item></parent_chain></comment><story><title>When to use Bazel?</title><url>https://earthly.dev/blog/bazel-build/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>yamtaddle</author><text>Right—in some sense it&amp;#x27;s not really Windows&amp;#x27; &lt;i&gt;fault&lt;/i&gt; 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&amp;#x27;s very non-unix, or that open-source software in general treats Windows the way web developers treat Firefox.&lt;p&gt;OTOH, in practice, if you&amp;#x27;re using a lot of open source tools and have developers working on every single halfway-plausible OS &lt;i&gt;except&lt;/i&gt; windows, things are probably pretty OK, but then you throw Windows in the mix and suddenly the time you spend supporting your builds &amp;amp; tools shoots way up. That makes it &lt;i&gt;feel&lt;/i&gt; like it&amp;#x27;s Windows&amp;#x27; fault.</text><parent_chain><item><author>trzy</author><text>All 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.&lt;p&gt;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.</text></item><item><author>yamtaddle</author><text>My experience is that Windows is a constant source of headaches if you&amp;#x27;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 &amp;amp; tools (probably why Make did better than Bazel).&lt;p&gt;I assume it&amp;#x27;s OK if it&amp;#x27;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 &lt;i&gt;way&lt;/i&gt; easier and more reliable when I switched to Linux. Luckily WSL2 is getting semi-decent and can call out to Windows tools, so it&amp;#x27;s getting easier to standardize on one or another unixy scripting language for glue, even if some of your tools on Windows are native.&lt;p&gt;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 &amp;quot;which copy of OpenSSH is this tool using?&amp;quot; It&amp;#x27;s probably less-bad if you&amp;#x27;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 &lt;i&gt;other&lt;/i&gt; things that might try to pile on more weirdness and unpredictability.&lt;p&gt;Those kinds of messes are &lt;i&gt;possible&lt;/i&gt; on macOS or Linux or FreeBSD or what have you, but generally don&amp;#x27;t happen. I think it happens on Windows because every tool&amp;#x27;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&amp;#x27;s a tendency for everything to end up with weird configurations that don&amp;#x27;t play well together.</text></item><item><author>trzy</author><text>Last year I tried doing a side project with a talented ex-Google buddy who insisted we set up Bazel to replace my simple Makefile. Three weeks later it still wasn’t working on my Windows box. We had a mixed Python and C++ code base and I like to use MinGW64 gcc on Windows. He blamed Windows and tried to get me to switch to Mac (no thanks, lol) and eventually he lost interest and gave up. The project went on to win an OpenCV funded competition and became the basis of a startup — good job, GNU Make!&lt;p&gt;So the answer IMHO to “when to use Bazel” is “never” :)</text></item></parent_chain></comment><story><title>When to use Bazel?</title><url>https://earthly.dev/blog/bazel-build/</url></story>