zig devlog ep1

After years of sticking to the languages I know, I decided to jump into a new language. I'm pretty passive when it comes to my interests, they always present themselves to me. I don't always know what draws me to a language, but in this case the obvious one was bun.sh. I've never used bun, nor did I previously have any interest in using it, but I did follow jarred for awhile and was impressed by his productivity. Clearly a very bright engineer. I also meandered onto a couple blog posts about zig recently and got the vibe that there was something special going on here.

One big consideration for me when learning a new language are its use cases. I want a new tool that can make me enjoy coding and be productive. Ideally, I see its potential to grow. I saw that pretty quickly when golang started gaining traction. I see a lot of similarities between zig and golang, at least on the surface.

Rust would be the obvious choice for a new language. I don't know, something about it feels too awkward. Everytime I read some of its code I feel the complexity of the language. I'm getting metaprogramming vibes and I'm not about that life. I want simple, readable languages and zig just has those vibes.

I usually try to pick a small tool that I would enjoy and even potentially use. I thought it might be fun to write a slightly more ergonomic curl or possibly a simple markdown formatter.

Anyway, I figured it would be fun to make a little series around learning zig.

I spent a week reading the docs and writing a toy program. There are a couple of things that stand out to me:

try is a great solution to error propagation
comptime feels dope but I don't fully grok it yet
the package manager is brand new

try is really neat and if golang adopted something like it people would shut up about error propagation.

I was able to install a third-party package using the built-in package manager but it was wholly unique compared to the other languages I use. I see zig.build as a potentially powerful build system that leverages writing code over configuration and with that lens it makes sense to include the package manager there as well. It wasn't as simple as something like zig install xyz, but I am slowly seeing why.

# refs