Cro: Maintain it With Zig

For upsides, for one, it's been around for 40 years, and there's a group working on the next ISO standard version. Like Fortran, it will be around for a few more decades. It's got more support than D or Nim or Zig, and unlike Go or Rust, I know it's going to be there for a while. (Look at Perl and Adobe Flash for other examples of shifting sands.) The military and aviation support will keep it alive, and AdaCore is dedicated fairly solidly to supporting the open source community.

For the other, it's a lot more powerful than C and a lot less hairy than C++. It's a fully object orientated language with generics, concurrency and Unicode support. The last update added a lot of support for invariants and the next is working on a lot of more convenient parallel processing constructs. SPARK is a formally provable subset, and there's subsets for running without dynamic memory allocation and for hard real-time systems.

I went hard into Ada after fighting with pre-ISO C++, and I sometimes group it in with my early years in BASIC, as something to be remembered more fondly than used, but SPARK is easier to use than Coq, and for a powerful language at the lowest level of the system, personally, Rust may be the only sane alternative.

Rust in particular stands out for its focus on safety and concurrency (and so, safe concurrency). Once upon a time concurrent programming was a weird niche case, and few needed to care about it. Then for a while it was more mainstream but still only something a few very low-level components needed, like a multi-processor operating system, but today it is likely that choosing not to do concurrent programming means choosing suboptimal solutions for an increasing range of problems.

Rust's type system allows it to assure you that your (safe) Rust programs exhibit Sequential Consistency. This means you can reason about the working of your concurrent program in terms of things happening in some order, e.g. if thread #1 did A, then B, then C, and thread #2 observes that C happened, it stands to reason that A has already happened, since that was before C. Modern CPUs do not actually experience Sequential Consistency, raw machine code for thread #1 that does A, then B, then C, will _not_ reliably result in a thread #2 which checks C happened also observing A having happened, so this really is some work for the compiler. In languages like C or C++ the compiler promises to deliver Sequential Consistency *if* your program is free from data races (cases where the same value could be modified simultaneously in two or more places) but if you fail the program not only doesn't have Sequential Consistency its behaviour is Undefined. Rust sidesteps this by making such races impossible in the language design. If you try to write a data race your program won't compile.

I think C++ stands out as the most friendly to would-be consultants. A consultancy career in C++ looks safe even if you started today, there's a lot of C++ out there and it's fantastically complicated, even if interest in the language for new projects wanes over the coming decades, I can't see an expert in C++ struggling to find consultancy gigs in 2050. And if C++ continues to go from strength to strength, that's just more opportunity for consulting. As a programmer having so many different ways to initialize a variable, plus the knowledge that some (but not all) variables in the language can be declared uninitialized, is annoying. But as a consultant that means even "variable initialization" becomes a topic heading, you can have policies, you can talk about existing practices, you can write an exercise, tonnes of fun.

As we see in the article, Zig has a remarkable cross compilation story. There are plenty of other small things to like about Zig, but I'd say the one that stands out is how enthusiastic Zig is about solving your build problem. If this dominates the work you don't like on a hobby project, that might be enough reason to adopt Zig even if nothing else about it appeals to you.

I suspect Go's niche is exactly what Google specified, although perhaps less than they had hoped. New hires can write a Go program that has reasonably good performance, and it probably either does what they expected or they've got a reasonable chance to fix the bugs and make it work. Go doesn't want you to be too clever, in fact it specifically cautions against this. But, it turns out that although it's not as dangerous as C or C++ it's still not actually safe, and although it's not as slow as Java or Python it's still not actually fast, and although it's easier to learn than Rust or Haskell it's still not actually easy. Trying to be the best would have involved being clever, and they didn't want to. If you can only ever learn one programming language, you could do much worse than Go. But if you can learn two, there's no reason I can see why either of them should be Go.