The Zig team makes the language exactly as I would want, even when they don't

Explain
1

Back in 2019, I switched to C (from C++, with experience in many languages). I did this in order to get better at computer science, and gain knowledge that would apply to my programming, whichever languages I ended up using in future. Over the years since then, I’ve run into various problems with C, and found my preferred ways of programming. Things like tagged unions, fat pointers, error handling, etc.

I’ve also had an interest in Zig during that time, and I’ve occasionally taken a look to see how Zig handles the things I find painful in C. Consistently, the Zig team has already solved the problem in exactly the way I would want, or in an even better way than I had thought of! However, there was one decision I didn’t like: removing @usingnamespace. As a game programmer, I often want to have the same types and basic functions available in the global namespace across many files. I can accept one wart on an otherwise brilliant language, but in my dissatisfaction, I decided to read through the git issue regarding this removal.

And, I must admit, the Zig team was right!

I read through the reasoning around the issue, and while the functionality of @usingnamespace was nice, I don’t think it’s worth having invisible declarations - that is, declarations present in the file’s namespace, with no hints about where they’re from. Let’s say the “bob.zig” namespace has a “jim” declaration. When you open bob.zig and CTRL+F “jim”, nothing comes up. Now you have to check every instance of @usingnamespace, which could be arbitrarily many files deep!

With the cost being greater than the benefit, I think a jankier solution to this problem is preferable. Either:

  • Just make a short namespace for these things.
  • Copy-paste the declarations to the bottom of the file, possibly with a nice big comment at the beginning and end to make it easy to search for and replace when the source declarations change.

All this is to say: even when the Zig team makes what I think is the wrong decision, they’re probably making the right decision.

Thanks Zig team!

PS: Sorry for the odd choice of category; I didn’t see one that fit better.

15 Likes
2

That’s nice, thank you. But don’t forget the Zig team can also be wrong and you should also think for yourself and challenge our opinions and reasoning.

33 Likes
3

My programming-language journey mirrors your own (just add Matlab to the front of the queue), and I could not agree more, including on the usingnamespace issue. Whenever I take the time to think about any particular issue related to error handling, type inference, interfaces, etc., then read the discussions that led Andrew and the Zig team to their particular solution, I find zero complaints with their decisions. This is why the (currently) only recurring donation I make is to the zig software foundation - they’re doing more for the field of software engineering than any other organization that I’m aware of. Keep up the good work @andrewrk :sign_of_the_horns:

4 Likes
4

Not to worry Andrew - I won’t become a sycophant! Once I’ve made a project with reasonable size and complexity in Zig, I’ll be sure to share my (polite) criticisms. Most of the criticisms I would so far offer already have planned solutions!

4 Likes
5

I feel like the way the language is growing has some major synergies with my main Zig project, my graphics engine/framework. For instance, just as my build.zig and the project’s modules had started to grow in complexity so much that I wasn’t fully satisfied with @cImport, they nudged me to switch to an explicit translateC module. And as I’ve been slightly unsatisfied with 0.16 zig build --watch, because it doesn’t pick up my new shaders, because it doesn’t rerun build.zig and re-parse my render.zon, I’ve read the devlog and seen that an upcoming release might improve this too!

It is genuinely so fun to figure out the language and the tooling in real time as it’s maturing. In my 10 years of developing random demoscene codebases, mostly in C++, C and Rust, nothing has ever come close to what I’ve been able to accomplish with Zig recently.

3 Likes