So I read this excellent article:
and decided to rename this thread from “Selecting Go or Rust” to “Selecting a programming language”. The point of all these discussions is not that one programming language is right and another is wrong, but rather that there are tradeoffs. The absolute safety of Rust is a benefit, but comes with the cost of complexity. A few quotes:
Using Zig for just a few hours has highlighted to me aspects of Rust that I’d never before considered. In particular, that much of the complexity I’d unconsciously attributed to the domain — “this is what systems programming is like” — was in fact a consequence of deliberate Rust design decisions.
For example, it’s now quite clear to me that Rust is a language which has a dedicated feature for everything. In addition to its famous borrow checker, Rust has modules, packages, generics, traits, two kinds of macros, attribute annotations, and a dozen other things.
A more complex language requires the compiler to do more work:
With Rust 1.50, a from-scratch debug build of my keyboard firmware takes 70 seconds (release, 90 seconds) and the
target/ directory consumes 450MB of disk.
Zig 0.7.1, on the other hand, compiles my firmware from-scratch in release mode in about 5 seconds and its
zig-cache/ consumes 1.4MB. Nice!
Lastly, some thoughts on small language simplicity:
“Small” is similarly easy; again, there’s basically one page of documentation. This value proposition is right at the top of the Zig Website:
Focus on debugging your application rather than debugging your programming language knowledge.
When I first started using Zig, I was dismayed that it was missing so many features that I liked from other languages. No syntax for ranges. No closures. No iterator syntax.
However, I ended up finding these absences liberating — this is where the “fun” comes in.
After two minutes of searching, I’d conclude “well, guess I’ll just have to suck it up and write a while loop” and then I’d get back to working on my problem.
I found myself more often in a state of creative flow, devising plans based on the limited capabilities of Zig and then executing them. This flow wasn’t constantly broken by stops for documentation or side-quests to investigate some feature/syntax/library.
This isn’t so much an observation of Zig alone as it is about my knowledge of Zig.
The language is so small and consistent that after a few hours of study I was able to load enough of it into my head to just do my work.
I have experienced the same feeling with Go and Elm – the languages are small with carefully chosen features. However, with advances in language design, even simple languages (like Go and Elm) can still be very reliable.
There is no perfect language – you must consider the strengths, weaknesses, and tradeoffs.