Something I don’t quite understand, coming from a scripting-language bqckground: why are you using your OS’s provided compiler toolchain (for anything other than building OS packages for distribution?) Is there no version manager for clang the way there is for e.g. Rust?

Speaking about the classical C/C++ mainstream, and more from the Linux perspective:

Tooling for C and C++ mostly relies on some external package manager, often the OS-provided one (on most Linuxes, for example). There isn't a standard cpan/npm/pip/cargo for C/C++, although there are plenty of tools that can do kind of the same thing.

There's also not much support for virtual environments (there are tools out there, but not ubiquitous tools). It's pretty easy to point the compiler to a different set of header files and libraries, even on a per-file basis, to get a similar effect.

And from the Apple side (which I have a vague understanding of, having dipped my toes in a few times): Most of the documentation assumes that you're using XCode, and I'm pretty sure that the version of the compiler is just tied to whichever version of XCode you're using (which has a somewhat looser tie to the version of MacOS you're running). So in that case, you'd be using the XCode-provided toolchain rather than the OS-provided one.

You can install GCC from Homebrew if desired. Personally I don't bother because, well, Apple's clang works just fine!

> Is there no version manager for clang the way there is for e.g. Rust?

Not an official one for sure, Cargo is a blessing for people used to dealing with C/C++ dependency management.

Macs ship with outdated versions of common bash commands and tools as well. Homebrew goes a long way to fixing this for me.

I have the same problem on Ubuntu LTS distributions. Eg the ancient version of git in 16.04LTS.

You can fix that of course but homebrew does the same job on macOS.

Roll on 18.04LTS.

Homebrew exists on Linux. I like running LTS distros because they just work. For newer per-project exceptions, I put everything into a container (again layered on LTS), it is esp nice for things like specific versions of LLVM which I wouldn't want to pollute my base machine with. My peronal userland gets shipped via, cargo, go, pip, npm, etc.

https://github.com/Linuxbrew/brew

I try to put everything our team does into a container for the same reason. I'd point out though that the version of docker listed by apt on 16.04LTS is also really ancient. Pre docker-ce.

Yeah, I install docker on to 16.04LTS via this install guide [0]. I'd happily use something else, and probably will, but docker is low friction.

[0] https://docs.docker.com/install/linux/docker-ce/ubuntu/

The most enjoyable and productive dev workstations I have used/setup have all used rolling release distro's for this exact reason.

It does have the overhead of requiring you actually understand (or know how to google) your system/packages that you use though.

It's not just understanding the packages. When I upgraded from 16.04LTS to 17.10 I had to relearn how to compile the kernel because my laptop would no longer boot.

Wasn't that hard to do in the end but it's not something I've done for many, many years and doesn't fill me with confidence.

BASH is outdated, but I compile the latest version and install it in /bin (I have system integrity protection turned off).

Other UNIX utilities are actually standard POSIX ones. If you are used to GNU extensions to these on Linux, then Mac ones may seem outdated, but ironically (macOS kernel is called XNU which stands for X is not UNIX) Mac is certified UNIX, while Linux is only UNIX like.