Kostya's Boring Codec World

Back when I wrote my rant about C++ and its bad influence on C (yeah, about three quarters of year ago) I got recommendations to look at Zig and finally decided to download 0.9.0 release and play it. Long story short: it’s an interesting language with some good ideas but not the one I’d use.

First of all, Zig feels more like a cross between D and Go, while Rust coming from ML family of programming languages ironically feels more like C—and I’m still a C programmer. The features like importing (sub)packages like const fs = @import("std").fs; or being able to compile C with the same compiler are well-known features of D. While postfix notation (e.g. var foo: u8 or pub fn main() !void), defer and having JSON support in the standard library definitely reminds of Go (and I was surprised to find support for various binary formats like ELF, COFF or PDB in std; compared to that std.Progress is nothing special). No idea though where pointer dereferencing as foo.* = 42; comes from. Additionally Zig has optional type and error built-in types which is a bit strange for a language posing as simple (in Rust they rightfully belong to the standard library as there’s nothing there that prevents them from being implemented in a language itself); probably it was a verbosity trade-off since Rust Option<OptValue> and Result<RetType, ErrType> is bulkier than Zig ?OptValue and ErrType!RetType respectively (and it makes applying special rules to those types harder).

And speaking of verbosity and error types, Zig is too verbose in all the wrong places. Error handling all works fine and try doStuff(); is no worse than doStuff()?; in Rust, the problems come when you don’t simply want to return on error. You can’t ignore return result and, developing further the infamous Go result, err := func(); idiom, you always have to process both values. While in Rust I can write if file.write(data).is_err() { ... } in Zig the compiler will complain if you don’t use actual error value in some way or if you do not use result value (but luckily you can send it to bit bucket) which means that proper code in this case looks like _ = file.write(data) catch |err| { silence_err_somehow(err); ... }.

Side note: I find Rust approach of making variables constant by default better in terms of preventing programmer from making certain class of mistakes (but it gets a bit annoying when most of your variables are mutable, so it’s more the matter of taste).

Then you have loops that disagree with my tastes. C has extremely powerful for(;;) loop, in Rust you have for X in Y loop taking an iterator plus there are ranges and other utility functions to replicate some of the C for(;;) features (e.g. for i in (0..10).rev().step_by(3) instead of for(i = 9; i >= 0; i -= 3)). In Zig you have for iter |item[, index]| and for the traditional C-like loop you have to use while with post-condition like while (i < 10) : (i += 1) {}. And I won't even talk about while with else clause.

What I really dislike though is rather inconsistent (again, to my tastes) language design. You have language keywords and you have built-in functions with rather arbitrary grouping. For instance, built-in functions include: package importing directives (@import, @cImport), type casting (@as, @ptrCast, @boolToInt), special instructions (atomic operations, @breakpoint, vector operations) and generic calculations (like @cos or @sqrt). I guess some of those were introduced to make for the lack of generics (and where comptime can't help) but I'd rather have many of those functions either moved into the standard library or associated with the proper types i.e. val.clz() instead of @clz(val) (and I'd make undefined a built-in function too instead of a keyword). And I'd like to have them separated in syntax by purpose. I'm not going to mention how it's done in Rust but even in C with all its deficiencies you had preprocessor directives starting with a grille sign e.g. #include and built-in compiler functions were conventionally prefixed with two underscores e.g. __builtin_clz(). The rest looked like normal language constructs and I didn't have to care how offsetof(struct, field) is implemented or whether the compiler is smart enough to use x87 instruction (or SSE nowadays) for cosine calculation. To repeat it again, I know that the current scheme is caused by some self-imposed limitations coming from the language and the compiler design principles but they don't align with me.

To offset negativity I should mentions some things in Zig that I found useful or at least interesting. First of all, not explicitly specifying array size (you can't do that in Rust for constants even if the compiler should be able to figure out array size from its contents). Built-in tests that have a free-form description are also a good idea (in Rust you can only name test function more creatively). Explicit wrapping operations for integers are nice (and writing foo -%= bar; is not as verbose as foo = foo.wrapping_sub(bar);). Sentinel-terminated arrays/slices is an interesting idea. Explicit compile-time calculations look very helpful. A dedicated opaque sounds like a good idea. The ability to compile C or C++ code is a nice feature (and I wish rustc would have a stand-alone assembly files support). There are some other nice compiler features (like cross-compiling out of the box) but they seem to be related to the compiler itself and not the language.

Overall, Zig is by no means is a bad language (and looks good enough to write a multimedia framework in it among other things), it just does not align well with my tastes. Let's wait and see how it develops.

This entry was posted on Saturday, February 5th, 2022 at 8:01 am and is filed under Useless Rants. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.