Ziglings: Learn the Zig programming language by fixing tiny broken programs
Neat concept.  Exploring the difference between what successfully compiles vs. what won&#x27;t seems like a great way of getting more familiar with the language.<p>I&#x27;ve written a little over 1,000 lines of Zig at this point and I really like it.  I think its key feature is a rich compile-time imperative programming environment (&quot;comptime&quot;).  If you can have full compile-time imperative code execution, you can get a lot of the benefits of more complicated language features (like C++ templates) &quot;for free.&quot;<p>In C++ templates are &quot;a language within a language&quot;, but even templates with all their complexity cannot solve all of the problems you might want to solve at compile-time, so C++ has been gradually expanding its compile-time code execution features so that more and more of the language is available at compile-time (constexpr, consteval, etc). Zig jumps straight to the finish line by making most of the language available at compile-time from the outset, and in doing so avoids the need to add the complexity of templates in the first place.<p>Having &quot;slices&quot; as a first class type feels like a general and powerful solution to the problems that std::string_view and std::span are trying to solve.<p>I am comparing Zig to C++ a lot, which many Zig fans would probably take exception to as Zig does not aspire to be a better C++, but rather a better C.  Indeed many key C++ patterns like RAII are explicitly out of scope.  But to me Zig bridges the gap between C and C++ by solving many of the problems that make C feel too spartan without jumping to the incredible complexity of C++.<p>There are a few things about Zig that give me pause.  I&#x27;ve noticed that compile-time feels like a very lazy environment, meaning that functions do not seem to undergo full semantic analysis unless they are called from somewhere.  You can write a function that compiles successfully, leading you to believe the function is syntactically and semantically coherent, only to find that when you add an actual <i>call</i> to that function, the compiler now flags errors inside that function.  This adds some friction to development, because the act of writing a function is no longer a self-contained activity.  Writing the function feels more like sketching it; later when you actually call it you have a new set of compile errors to contend with.<p>I also miss tools like ASAN to catch memory errors.  I&#x27;m guessing things like that will come with time.<p>Overall I feel very positive on Zig.