Zig induces a craftsmanship culture

This is just an amorphous braindump from an introspection I had the other day.

The act of developing in Zig has shifted me to a state of “zig-ifying” my setup, the tools I usually use for my day-to-day craft. The closest I could get to a relatable concept was Monozukuri - Wikipedia, which might not be entirely accurate, but is good enough.

Upon reading other topics here I noticed there’s an implied (although eventually explicitly named) culture of building from the ground up rather than resorting to dependencies.

I think overall the geist of the language and the community is one that influences in the direction of craft betterment and this is a good thing. Heck, I see myself reading more papers and studying more to self develop as an engineer and I attribute that to learning and getting involved with Zig.

Thanks a lot for that!

31 Likes

It’s all about software you can love shameless plug.
It aims to go beyond this humble community, we aren’t the first nor biggest to emphasise it, yet, but the more, the merrier.

4 Likes

It’d be great if this year’s Software you can love happens in Stockholm or nearby so I could join :slight_smile:

Would be nice to have an in-person event to learn about Zig. :slight_smile:

3 Likes

i dont know if there is one this year, but 2026 will be in Vancouver

3 Likes

Zig produces a feeling like it’s the 2000s and you’re learning C. The online resources are not that reliable, LLMs are donkey sh, and you are forced to ask other people for help. Either trough a forum or in person, but that takes time, so you also turn to reading the manual as in RTFM. And it’s hard at times, but the satisfaction of building is immeasurable compared to other platforms. Kinda hoping this feeling doesn’t go away.

19 Likes

It’s hard to organize SYCL far away from where the organizers live (me in milan, mattnite in vancouver), but you can get a key part of that feeling by joining a Zig Day, and coincidentally there’s one in Stockholm :^)

8 Likes

That’s fantastic. I’ve just subscribed, thanks a lot :slight_smile:

Well spoken!
I definitely have the same feeling.
The language and the libraries invite the programmer to be in charge and craft excellent software.
In C++, Rust, Java, Kotlin, it’s like you have to negotiate with the library and the compiler, and you always lose the negotation.
To me it feels like Zig has just the right amount of restrictions. It will prevent you from doing obviously wrong thing, but won’t stop you from doing smart things.

One of the most liberating experiences I have in Zig (coming from Rust) is how you tend to use the language’s own control flow instead of trying to express yourself through layers of indirection and “cleverness”.
You wouldn’t do functional chaining mylist.iter().filter(...).map(...).try_collect()? like in Rust. Not because it can’t be done, but because the control flow is convenient in Zig. Just normal for, while, if, orelse … I love it.
Another liberating thing is how all fields are public.
I choose to regard it as a targeted assault on nonsensical Java dogma :smiley:

11 Likes

Yeah, I’m approaching 40, I’ve seen a lot of languages and programming methodologies, but discovering Zig and its ideas, its spirit, its practices has been one of the pivots in my whole relation to computers and code, I feel more and more enlivened by Zig each day that passes!

8 Likes

The part that I like about the “craftmanship attitude” of Zig is that it’s not something that arose (entirely) as a result of the community around the language, it’s something that arose out of the compiler design and the Zen.

In C you get a lot of “this is kinda bad but I’ll fix it later”, whereas in Zig you get a lot of “this is kinda bad, I have to fix it right now or else it won’t compile”.
This is a big deal, because it essentially requires you to write your code right the first time or not write it at all.

6 Likes

I also really like how try and the @casts makes it obvious which parts of your code is fragile. Making it obvious where code can fail is such a big part of designing code that won’t fail.

( comptime errdefer unreachable my beloved. )

5 Likes

There is definitely a strong culture of anti-dependency – or I guess suspicion towards dependencies. But I think the bigger point is suspicion towards abstractions.

These are related because libraries can often be replaced by code that is a fraction of their size if you are willing to remove abstractions and write simple, “dumb” code that does only what you need it to do.

A massive, complicated serialization library like serde could be replaced by a small amount of standard library code that reads and writes structs directly. Your code won’t be beautifully abstract with pluggable backends and so on, but do you actually need that? For my database the answer was “no” so I just did the dumb thing and it was fine.

This is what I constantly discovered while using Zig. If I just solve the actual problem I’m working on, and not a thousand theoretical problems, I can accomplish so much – and my code will be far more readable because it is direct, rather than going through a dozen layers of “beautiful” abstractions.

11 Likes

That’s such an awesome idiom. Everyone who has analyzed a big block of code hunting for error pathways knows that mental model you build up - “I know my code overall can error, if I made it to this point in the code, then I’m not going to”. The fact that we can get the compiler to prove that without any refactoring, just a single line of code in the right spot, is amazing.

4 Likes

Nicely said!

Zig encourages this, but it also can be applied to coding in other languages once you have learned it. So even those who don’t plan to use Zig can benefit from learning it and learning this approach.

3 Likes

Yes, that’s a really good way to put it. I work as an embedded software engineer, and since I started earlier this year at a new company, using C++ has been a dreadful experience. To be fair, I’m definitely stronger in C than in C++, so a lot of it is skill issues. But good lord, that language is painful to use.

For example, I recently ported a custom Raspberry Pi computer vision pipeline. I basically reimplemented some opencv ish functionality in C, and not only was the code cleaner, but it also compiled about 20x faster. While I was porting that awful C++ code, I was actually enjoying myself for once. And yet, at every step, I couldn’t help but think: this would be so much simpler in Zig.

One of the underrated perks of Zig, which I don’t see many people talk about, is the confidence it gives you. Because it’s actually strongly typed, because it’s hard to make dumb mistakes, and because the tooling + stdlib + ecosystem are just solid, you finally get to push your code further without that constant fear of things blowing up in subtle ways.

Maybe that’s just me being junior, but honestly there’s a good 20/30% of optimizations I don’t even attempt in C/C++. The ROI is just not there the time, the pain :sob:, and the risk of adding insane complexity make it really hard to justify.

Take custom allocators, for instance. Sure, you can do them in C, kind of similar to Zig. But the moment you pull in a library, you almost always lose control. In C++ it’s even worse: if you want to avoid the compiler secretly copying stuff everywhere, you have to dive into perfect forwarding, disable copy constructors/operators explicitly, and jump through hoops. And that’s just one example.

Yes, some of this is skill issues, but the fact remains: Zig not only encourages a kind of craftsmanship culture, it’s designed from the ground up to make it easy to do what you want to do without forcing you to stop at some ugly local maximum of “well, I guess that’s the least painful way in C++”

Because obviously techincally you can implement everything in every language, and as long as llvm is behind the codegen, you could technically get the same performance, but from a practical standpoint, there is really not a lot of languages, that i know of, that gives you the kind of confidence, speed of iteration, and power to build complex and performant system as well and as easily as Zig.

Honestly I’m really excited for Zig’s future, what really convinced to invest early was the fact that on top of being a better C in my eyes, unlike other low level languages, it’s designed by a very competent, ambitious, team with a strong vision of what they want to do, and that gives me a lot of confidence that it won’t end up like Nim or V or any other language that start as lean C/C++ competitors and because they lack focus and identify they start to become yet another C++. What kills language for me is really a lack of of consistent vision, every language designed by the community or by a committee is most likely going to end up in the same kind of mess that is C++.

15 Likes