4 ms·

I've written a lot of Zig, including a somewhat popular http framework, a driver for PostgreSQL and one for DuckDB. Personally, I feel that if you want to grow

by latch 2y ago

I've written a lot of Zig, including a somewhat popular http framework, a driver for PostgreSQL and one for DuckDB. Personally, I feel that if you want to grow as a programmer, no matter what you're doing, there's little that offers more bang for your buck than learning C. You can pick up C relatively quickly, and that knowledge will serve you (maybe mostly indirectly) throughout your entire career. Learning Zig is a much better option. Too many quality of life improvements over C, and you still learn the same fundamentals. If you're interested, I wrote something that might help (1). As for _using_ Zig. I think it's a good idea to take a conservative view and assume the ecosystem is hostile. The quality of test coverage of the standard library varies. Breaking changes are frequent and aren't always trivial. 3rd party libraries are often abandoned and many are written by people learning Zig (including my own!). It's really great for learning/side/fun project because you can get distracted for weeks writing something you never intended to. It's not actively hostile, but I think approaching it that way will help manage expectations. I would strongly consider tracking the master branch. If you write anything substantial in Zig, you will 100% run into a must-have bug-fix or feature in the stdlib or 3rd party library that depends on on 0.13.x development commit. (1) - https://www.openmymind.net/learning_zig/ https://www.openmymind.net/learning_zig/

RetroTechie 2y ago
Zig is positioned as a sort of "better C", correct? With that in mind, how does Zig compare to C, complexity-wise? Both for learning, and its implementation. Is it a 'bigger' language than C? Just different? Easier to grasp? Or takes more effort to get a good understanding of? About the same as C? Anyway: a very promising project. Nice to see it progressing towards a mature ecosystem.
- flohofwoe 2y ago
  IMHO (not the parent): from the perspective of a C programmer, Zig is several things: 1. A "better C" in the sense that the language core of Zig fixes the commonly known and accepted design warts of C which are hard to fix because of backward compatibility requirements - this part is actually less complex and easier to learn than C because there's less implicit and less unexpected hidden behaviour while having roughly the same "language surface". If you are used to C's somewhat sloppy "hippie-approach" to programming, be prepared that the Zig compiler will yell at you a lot at the start of the learning phase, especially when it comes to implicit type conversions which follow very strict rules in Zig (when compared to C). 2. A much richer and actually useful stdlib (in this area Zig is also a much better C++), don't quite expect a Python-style "batteries included" stdlib though. 3. A much more complete compiler toolchain package, with a build system, package manager, C/C++/ObjC integration and cross-compilation to the important target platforms included and working out of the box (and most of that integrated into the Zig executable, a vanilla Zig install actually only has a single executable, the Zig compiler). 4. And finally the "visionary part", where Zig differs most from C and other languages and explores its own path, like the approach to comptime, generics, type reflection and error handling.
  - latch 2y ago
    To add more concrete examples, you could look at tagged unions, errorsets and optionals. An `if` statement in Zig has a few different faces, traditional condition, unwrapping an optional and unwrapping an errorset. That makes the language "bigger", but these are things you'll regularly face in C anyways, even with trivial examples. I think most of the things Zig (purely as a language) has "added" to be labeled a "Better C" are all pragmatic and don't increase any cognitive load. The other thing worth mentioning is that Zig has a number of safety advantages. I just touched up my DuckDB driver, and their C API exposes the underlying storage for a column as a (void ), the format of which depends on the column type. In Zig, I can map this to a typed tagged union. For an bigint column, instead of a (void ), I end up with an []i64.
  - throwawaymaths 2y ago
    Even if you never use zig generics --if nothing else eliminating fucking spiral types is enough of a quality of life improvement alone that you should consider zig over C. if you've never heard of them: https://c-faq.com/decl/spiral.anderson.html https://c-faq.com/decl/spiral.anderson.html I'm not even sure if the faq is in jest or not.
    - flohofwoe 2y ago
      This "spiral type notation" has been acknowledged in K&R 2nd Edition as one of the less fortunate design decisions in C.
    - pjmlp 2y ago
      Ironically, almost 40 years later Pascal linage of languages finally have their revenge in type declarations.
    - jstimpfle 2y ago
      The clockwise/spiral rule is a misunderstanding, it doesn't exist and C type syntax is not that complicated. The thing that isn't well known about C type syntax is that there is no type syntax. At least originally, there wasn't really type syntax. (This was later muddied by e.g. types in function signature parameters, which came from C++ -- and which are a good thing to be clear). Types follow usage (given as normal code expressions), and if you can read normal expressions, you'll know what a type declaration means. The syntax is simply: type-name EXPR. where type-name is a simple name (or tagged name, such as struct mystruct), and EXPR is a limited subset of normal expressions. Example: int *foo[10]; Read like (type-name = int), (EXPR = *foo[10]). Now, if you now how to understand the EXPR, you'll know what the type of the variable foo is. Since (*foo[10]) must be int, you can simply go backward to know the "shape" of foo. Similarly, there is some elegance how to define a type name instead of a variable -- you simply add the "typedef" keyword and that's it. Even though that idea is a bit arcance admittedly, and not so pure anymore today, now I'm used to the C way of declaring types, and I think I like the fact that there isn't much of an additional syntax. Maybe it even removes mental overhead when reading code.
deleted 2y ago
[deleted]

by latch 2y ago

RetroTechie 2y ago

Zig is positioned as a sort of "better C", correct? With that in mind, how does Zig compare to C, complexity-wise? Both for learning, and its implementation. Is it a 'bigger' language than C? Just different? Easier to grasp? Or takes more effort to get a good understanding of? About the same as C? Anyway: a very promising project. Nice to see it progressing towards a mature ecosystem.

flohofwoe 2y ago
IMHO (not the parent): from the perspective of a C programmer, Zig is several things: 1. A "better C" in the sense that the language core of Zig fixes the commonly known and accepted design warts of C which are hard to fix because of backward compatibility requirements - this part is actually less complex and easier to learn than C because there's less implicit and less unexpected hidden behaviour while having roughly the same "language surface". If you are used to C's somewhat sloppy "hippie-approach" to programming, be prepared that the Zig compiler will yell at you a lot at the start of the learning phase, especially when it comes to implicit type conversions which follow very strict rules in Zig (when compared to C). 2. A much richer and actually useful stdlib (in this area Zig is also a much better C++), don't quite expect a Python-style "batteries included" stdlib though. 3. A much more complete compiler toolchain package, with a build system, package manager, C/C++/ObjC integration and cross-compilation to the important target platforms included and working out of the box (and most of that integrated into the Zig executable, a vanilla Zig install actually only has a single executable, the Zig compiler). 4. And finally the "visionary part", where Zig differs most from C and other languages and explores its own path, like the approach to comptime, generics, type reflection and error handling.
- latch 2y ago
  To add more concrete examples, you could look at tagged unions, errorsets and optionals. An `if` statement in Zig has a few different faces, traditional condition, unwrapping an optional and unwrapping an errorset. That makes the language "bigger", but these are things you'll regularly face in C anyways, even with trivial examples. I think most of the things Zig (purely as a language) has "added" to be labeled a "Better C" are all pragmatic and don't increase any cognitive load. The other thing worth mentioning is that Zig has a number of safety advantages. I just touched up my DuckDB driver, and their C API exposes the underlying storage for a column as a (void ), the format of which depends on the column type. In Zig, I can map this to a typed tagged union. For an bigint column, instead of a (void ), I end up with an []i64.
- throwawaymaths 2y ago
  Even if you never use zig generics --if nothing else eliminating fucking spiral types is enough of a quality of life improvement alone that you should consider zig over C. if you've never heard of them: https://c-faq.com/decl/spiral.anderson.html https://c-faq.com/decl/spiral.anderson.html I'm not even sure if the faq is in jest or not.
  - flohofwoe 2y ago
    This "spiral type notation" has been acknowledged in K&R 2nd Edition as one of the less fortunate design decisions in C.
  - pjmlp 2y ago
    Ironically, almost 40 years later Pascal linage of languages finally have their revenge in type declarations.
  - jstimpfle 2y ago
    The clockwise/spiral rule is a misunderstanding, it doesn't exist and C type syntax is not that complicated. The thing that isn't well known about C type syntax is that there is no type syntax. At least originally, there wasn't really type syntax. (This was later muddied by e.g. types in function signature parameters, which came from C++ -- and which are a good thing to be clear). Types follow usage (given as normal code expressions), and if you can read normal expressions, you'll know what a type declaration means. The syntax is simply: type-name EXPR. where type-name is a simple name (or tagged name, such as struct mystruct), and EXPR is a limited subset of normal expressions. Example: int *foo[10]; Read like (type-name = int), (EXPR = *foo[10]). Now, if you now how to understand the EXPR, you'll know what the type of the variable foo is. Since (*foo[10]) must be int, you can simply go backward to know the "shape" of foo. Similarly, there is some elegance how to define a type name instead of a variable -- you simply add the "typedef" keyword and that's it. Even though that idea is a bit arcance admittedly, and not so pure anymore today, now I'm used to the C way of declaring types, and I think I like the fact that there isn't much of an additional syntax. Maybe it even removes mental overhead when reading code.

deleted 2y ago

[deleted]