Hacker News new | ask | show | jobs
by jokethrowaway 1553 days ago
I don't comprehend how people can develop on windows (without linux subsystem).

I have to do that every once and then (to ship the occasional C++ or Rust build on Windows) and it's the stuff of nightmare. Stuff breaking randomly from one day to another, env variables to be set in weird ways, GUI installers, 8 different versions of mingw or similar. Recently I've seen that there are a few package managers now (I used chocolatey and at least 2 others just trying to get something to compile) but still, compiling something trivial is always an adventure.

Mac OS X is kind of okay. Brew is barely decent and things mostly work (unless you discover you need to install 12GB of XCode for some dependency or your script is expecting coreutils instead of bsd).

Every linux distro comes with a package manager and compiling is trivial

5 comments

Homebrew is a subpar choice on macOS; MacPorts is faster, has more packages, and is implemented more correctly than Brew.

Additionally, MacPorts was co-created by an engineer who also created the original FreeBSD Ports system, and thus hews much more closely to standard UNIX/BSD practices.

I’m not sure how and when Homebrew became the standard, but it is definitively worse.

I came to realise this too.

Using Homebrew and multiple users is excruciating and an eye opener on how system-level software should really be installed.

Homebrew insists on avoiding root privileges whilst also installing packages system-wide. That works fine and is invisible with one user but falls down hard otherwise.

Their documentation is incorrect too, saying that this is all fine because “we install in /usr/local/bin”. It’s not easy to change this.

The solution was to embrace MacPorts which correctly requires root privileges to install system-wide packages.

I haven’t looked back since. I haven’t missed brew or any software that’s available on brew alone.

Too bad when I want to install newer fancy tools on Linux, it's easier to unify the environment with Homebrew instead of using Homebrew only on Linux (which has a very weird quirk that it wants to install in /home/linuxbrew/.linuxbrew (or else it'll start compiling so many packages instead rolling binary packages) instead of /opt/homebrew like any sane decision would've been.)

I also don't understand Nix when it wants to make 30 users for build process and a few unintuitive decisions. Otherwise it's good that it works same on macOS and Linux.

For me compiling usually is something like `cargo build`, `ng build`.

I remember having problems with libs that require installing & registering a library somewhere such that CMake can find it. However, I distanced myself a bit from C(++), so that doesn't really happen anymore :)

I avoid mingw, don't use any package manager besides Windows Store (if you want to call that a package manager).

Can't complain. Sometimes, there is stuff that simply doesn't support Windows -> WSL. When there is docker, it doesn't matter anyways...

My strategy is don't fight Windows and you'll be happy

From your description it sounds like you might be going off the beaten track and hitting problems.

When I was doing C++ on Windows getting a dev environment setup just meant installing Visual Studio with an appropriate Windows SDK version (or the Windows SDK + build tools for a build system).

You can have multiple VS versions installed side-by-side. To get a terminal with environment variables set correctly you just need to use the shortcuts from your VS installation.

For third party dependencies we checked the headers and (pre-built) binaries into the repository. I don’t remember ever having more than a dozen or so in total. It was usually things like boost and zlib.

Having done that you can just point CMake directly at the packages rather than worrying about FindPackage.

Working in tools like Python and Node, personally I often miss the simplicity and stability of this approach.

> I don't comprehend how people can develop on windows

They want to distribute their app on Windows?

That’s why, not how. And you can cross-compile from Linux for some stacks.
It's easier to target Windows from Windows than from Linux.
It's usually not by choice. Medium to large enterprises often demand this so they can manage the employee hardware.
It depends a huge amount on the language and toolchain.

MSVS is really quite nice.