yujiri.xyz

Software

Zig review

Overall, Zig is my favorite language right now. It has many brilliant, elegant ideas, like the ways you use comptime to replicate the benefits of powerful type systems without making the languge too complex, and that files are structs.

i also think that its ethos is a sort of antidote for the rot that's eaten most of the software world. I like that it doesn't depend on libc, is working on native codegen instead of hard-depending on LLVM, is conscientous about supporting non-mainstream platforms (there's even some Plan 9 stuff in its stdlib), is planned to have a formal specification and not have its own package repository. It also gets insanely good performance and small binaries.

Despite my emotional favoritism for it, i'm under no illusion that it's as practical as higher-level languages for writing application software. Manual memory management and not having closures is quite pain, also trait objects are hard because you have to make vtables manually which takes a lot of boilerplate, but I don't consider those things flaws as it's meant to be a low level language.

Error system

They advertize "Zig is designed such that the laziest thing a programmer can do is handle errors correctly", and they did a really good job with that, they achieved it in a way Rust didn't, mostly because thanks to error set inference, you don't have to fuck around with sum types to be able to return more than one error type from a function. The compiler infers and flattens the set of possible errors a function can return.

The error system has some serious limitations though. Errors are *just* the name of the error type, they don't support carrying a detail payload. For example, if you're writing a parser, you can't return `error.InvalidChar{.line = 7}`, you can only return `error.InvalidChar`.

Likewise, there's no way to *wrap* an error with context, as in the Go library github.com/pkg/errors. You get error return traces in debug builds, which are similar to stack traces, but no tools for wrapping an error for end user display.

https://godocs.io/github.com/pkg/errors

Tooling

It has a good formatter which has no configuration, uses 4 space indentation (I'd prefer tabs but this is alright), and instead of trying to always take responsibility for line breaks like rustfmt, it uses whether there's a trailing comma to decide whether to break a list onto one line per element, which is wonderful!

Cross-compilation is easy, you can just passs `-target $target` to the build command.

Errors that should be warnings

Unused variables are compile errors. I complained about this when I wrote my earlier review of Go, but Zig is even worse, because unused *function parameters* are also errors. In Go it's only non-parameter local variables. This is a big hassle when you're just trying to test something.

Go review

Hidden pass-by-reference

Zig reserves the right to optimize by-value function parameters to be by-reference instead. I get the intention here: the compiler is probably better at figuring out whether passing by reference is worth it than a human. But what I hate about this feature is that it creates this hidden pass-by-reference footgun:

https://github.com/ziglang/zig/issues/5973

I consider this a serious mistake and hope they'll still reconsider it before 1.0 🙁

Lack of ergonomics

Debug-printing things is a bit of a pain: `std.debug.print("message\n", .{});`. The newline is not added automatically (there isn't a variant function that adds it), and you have to write the argument tuple `.{}` even if it's empty.

Imports are a little more verbose than most languages, because you can't import multiple symbols in one line. This is the standard stuff that goes at the top of every file:

In fairness, this makes it easier to search for where something is defined.

There is no operator overloading. For types that aren't primitive but that have reasonable interpretations for arithmetic operators, like Raylib vectors, you have to write things like `raylib.Vector2Add(raylib.Vector2Subtract(a, b), c)` instead of `a - b + c`. (You also can't pull all of those functions into your namespace because, again, there is no glob import.) You can't even use `==` on non-primitive types. You have to use `std.mem.eql` for slices, and `std.meta.eql` for structs and unions.

There are no closures, so despite that there are generics, you can't implement many useful collection methods like "find item by closure". Generics seem to be mostly useful for defining data structures.

You can't destructure nullability and a sum type at the same time; you have to use two levels:

In Rust you could write:

Abundance of ergonomics

On the other hand, there are some areas where Zig is more ergonomic than other languages, like the ability to omit type names when Zig knows what type to expect. For example, note how in the switch in that last example I didn't have to write `T.a` and `T.b`. Likewise, if I'm reurning a `T` from a function in Zig I can write `return .{.a = 4}`, instead of `return T{.a = 4}`. This is *really* nice for functions that take enum arguments. You can just do `func(arg, .variant)`.

Another ergonomic win is default values for struct fields. You can just put a default value when defining the struct, instead of having to write a constructor or implement a Default trait.

Now the big one: the `orelse` and `catch` keywords for unwrapping optionals and error unions are sometimes outstandingly more flexible and concise than the equivalents in other languages. Compare them to Rust's `?`, which translates to `orelse return null` for optionals or `try` for error unions. `?` is, at first glance, shorter than either. But it only works when the function returns the right type. For example, if your function returns nothing, it can't use `?`; you have to write this:

Whereas in Zig you can just write `orelse return`. This specific case has come up surprisingly often for me in both languages.

You also can't use `?` to short-circuit to a scope other than the function. To unwrap an optional with a default value, Rust gets longer: `?` becomes `.unwrap_or(default)` or `.unwrap_or_else(|| default())` if the default value is a function. While Zig gets shorter: `orelse return null` becomes `orelse default()`. You can even use Zig's `orelse` and `catch` to short-circuit to intermediate scopes like loops and labeled blocks: I use `orelse continue` very often! In Rust you'd have to resort to the verbose `match` block in those cases.

I think what Zig's designers realized that Rust's didn't is that syntax is more flexible than methods because it doesn't force a new scope. You can easily make a new scope with Zig's tools if you want, but you don't have to.

And shall we compare to exception languages? Consider this Python code:

Versus:

Zig blows it out of the water, which is really surprising comparing a low-level language to a dynamic one.

Of course, you could show plenty of examples where Zig would be similarly or more verbose than Python, but I'm just so impressed and intruiged that it competes with higher-level languages in these ways.

Accessing a union field

I don't like that accessing a union field looks the same as accessing a struct field. Don't have much to say about this, I just feel it's unclear.

contact

subscribe via RSS

Proxied content from gemini://yujiri.xyz/software/zig.gmi

Gemini request details:

Original URL
gemini://yujiri.xyz/software/zig.gmi
Status code
Success
Meta
text/gemini; lang=en
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.

What is Gemini?