There are some very clever concepts in Zig (I like the fact that types are compile time values), but the language doesn't seem to be as carefully designed as some others. For example, for-loops only work on a few, blessed types.
Zig offers a radical design. It seeks to be as simple as C — which is particularly important in low-level programming for both portability [1] and humans and machine analysis — while also giving you safety and high expressivity. Obviously, radical design means doing things differently.
Zig rejects any kind of implicitness; all calls must appear as calls. This means no operator overloading, no destructors, and no magical traits. It does so, however, without giving up on expressivity by using other mechanisms.
All low-level programming languages suffer from low abstraction. That comes with the territory. By that I mean that implementation details (especially around memory management) are hard to hide. Changing those details in some component often require changing the clients of that component as well. But C++ and Rust have a design philosophy that tries to hide this intrinsic quality of low-level programming by making the final code appear on the page as if it has abstraction capabilities similar to high-level languages. Of course, that illusion breaks as soon as you try to change code, and it's debatable whether this design helps or harms program comprehension. Zig rejects the C++ philosophy in favour of a brand new, and pretty revolutionary one, that reimagines how low-level programming is done. Unlike Rust, Zig isn't a cleaned-up C++ with a few extra tricks, but it isn't a new C, either. It's something completely different.
You might prefer Zig's design for this domain (as I do) or you might prefer the more traditional C++ design, but the great thing is that Zig is so simple and easy to learn that it's easy to try and find out.
[1]: Consider what it would take to port C++ (or a C++-like language) to new microcontroller you build. You would either need to port LLVM or an extremely complex compiler — a huge undertaking. This is why C (well, there's a tiny bit of Ada, too) still reigns supreme even in domains where correctness is of utmost importance: https://youtu.be/uqan23518Yc?t=632
The more I use Rust the more I am convinced I can write high level performant code. I mean it's ridiculous that sometimes I forget I am writing Rust and not Scala!!
As someone who does a lot of low-level development, before Zig I didn't think any approach other than that of C or that of C++ was even possible. I don't know if Zig will fulfil its promise, but its radical design, that's unlike anything we've ever seen, sure offers a fresh perspective on things.
As to static guarantees -- they are never the point; they are a means to an end: writing more correct programs. That goal is just as valued by Zig as it is by Rust, Zig just tries to achieve it differently. Which achieves it better? It's hard to know right now. I have little doubt that Rust could make things that are today written in C++ safer, but I have serious doubts whether it would be adopted in truly safety-critical domains, where C is king. I think Zig could be.
I didn't know Zig can provide memory safety using it's features. If that's the case it's great, I need to try it out! Although I am sceptical about the claim that in truly safety-critical domains Rust would not be adopted where Zig would, but I am again out of my depth here, so :)
Yes, although this is done through runtime checks (that can be optionally disabled) rather than through static sound guarantees (Rust uses runtime checks in some cases, too). The language's simplicity and fast compilation helps with other types of correctness, too (i.e. beyond memory safety).
> Although I am sceptical about the claim that in truly safety-critical domains Rust would not be adopted where Zig would
I don't know if Zig would, but Rust has several problems for such domains that C and Zig don't: porting it is a challenge (both Rust itself and LLVM are very complex), understanding what a program does is a challenge (a lot of implicit behaviour), and handling allocation failures is a challenge.
Zig also has the same issue with LLVM until the language is fully bootstraped and the original LLVM based compiler no longer part of the build process.
However, packaging a C and C++ compiler alongside for the ride doesn't make it that much simpler.
That might not matter. Porting Rust might not be a simple undertaking, either.
> Zig also has the same issue with LLVM until the language is fully bootstraped and the original LLVM based compiler no longer part of the build process.
Yes, but that's expected to happen before 1.0.
> However, packaging a C and C++ compiler alongside for the ride doesn't make it that much simpler.
C isn't an issue at all; C++ is. I'm pretty sure it could be made optional.
Procedural macros are also somewhat insane in many ways.
It seeks too, but fails. Comparing to really-simple C, it's full of arcane stuff.
> Zig rejects any kind of implicitness; all calls must appear as calls.
We already have that in C.
> Of course, that illusion breaks as soon as you try to change code
That's one of the traits of Zig too it seems. My favorite example of Zig's poor design is following case:
Suppose you have a function call:
collectNoInline(gc);
@call(.{ .modifier = .never_inline }, collectNoInline, .{gc});
I'm sorry, but that's total nonsense. Shows that not enough good faith went into Zig design. Even in C, that could be syntactically annotated as:
/*pragma:noinline*/
collectNoInline(gc);I think it's quite the opposite. Don't forget that C also has macros and a lot of arcane undefined behaviour. I don't know if Zig is as simple as C -- it doesn't have macros but does have, say, slices and comptime -- but it's also much safer and much more expressive. Overall, it's a very simple language, that's very expressive and also quite safe.
> That's one of the traits of Zig too it seems.
Absolutely! It's a feature of all low-level languages. Zig, however, unlike C++ and Rust, doesn't try to waste its complexity budget on making it seem like a high-level language when you just look at the code on the page (and it has other downsides, too, besides language complexity).
> I'm sorry, but that's total nonsense. Shows that not enough good faith went into Zig design. Even in C, that could be syntactically annotated as:
And I'm sorry, too, but I would say it's an example of Zig's exceptionally great design at this stage. If at some point it turns out that adding a new kind of syntax element here is worthwhile, it can always be added later. When in doubt -- leave it out. You never know when your complexity budget is best spent, and if you already have a general means of doing something without a new syntactic category, it's best to wait and see.
C lexic-based "macros" are implemented by a separate component, "C preprocessor". C clearly needs a AST-based macros, not a whole new language to replace it. Undefined behavior comes from the fact that C is machine-independent assembler (with structured syntax), so to be exactly that ("machine-independent" and "assembler"), it has to underspecify machine-specific matters, like what happens if you shift 32-bit number by 33 bits.
> I don't know if Zig is as simple as C -- it doesn't have macros but does have, say, slices and comptime -- but it's also much safer and much more expressive. Overall, it's a very simple language, that's very expressive and also quite safe.
Those are points which I doubt - it's clearly not expressive enough, and there're safer languages either. Is there niche for it? I'm on a fence with popcorn. But as I look to it, I see things which I consider "mistakes". And I love to talk about mistakes!
> And I'm sorry, too, but I would say it's an example of Zig's exceptionally great design at this stage.
Expectedly, I don't buy this "worse is better" argument either. It's not good when you annotate a simple call and it turns from a simple call into an ugly mess. It's not rocket science to come with a syntax which would avoid that. If Zig language creators didn't do that so far, that's exactly what I call "not enough good faith went into Zig design".
Your appendix of "so far" is accepted - keep up the great work!
But that "whole new language" is probably smaller than just AST macros for C. And C's problems aren't solved just by fixing macros (I think AST macros are a horrible feature in almost any language that isn't a Lisp; I see them as a sign that the language designers just gave up).
> Undefined behavior comes from the fact that C is machine-independent assembler
True, but that's almost never a valuable thing these days; you lose portability and get little in return other than a somewhat smaller compiler.
> it's clearly not expressive enough
It's at least as expressive as any other low-level language. Any C++/Rust program -- with generics, concepts, destructors, async, traits, macros -- could be translated to an equivalent Zig program that's at worst no longer than some (small) constant multiple of the original. That's not true for C (at least not without hurting performance).
> and there're safer languages either
Low-level? Not so sure. The goal is a language that makes it easy to write correct programs, not "a safe language". I'm not sure there are languages that do that better.
> I don't buy this "worse is better" argument either
It's an "it's just better" argument. Good design is not about picking arbitrary things and making them more convenient, but about spending a certain budget in a way that yields a good gestalt.
> It's not rocket science to come with a syntax which would avoid that.
Sure, but you can add that syntax at any time. It's not urgent. It's best to see if you could perhaps generalise it in some way and get a better return, or maybe invest your complexity budget more wisely elsewhere. I doubt compiler directives make up more than 0.1% of a program.
> If Zig language creators didn't do that so far, that's exactly what I call "not enough good faith went into Zig design".
I've been programming for ~30 years, and aside from Scheme -- maybe -- I don't think I've ever encountered a better-designed language than Zig. Of course, this perception is subjective.
The status quo for iterators is this:
var it = getSomeIterable();
while (it.next()) |item| {
...
}
I understand where it's coming from, but having something like "for (i32 i in [0,n[)" would be so much nicer in my opinion.
You can do:
var i: usize = 0;
while (i < 10) : (i += 1) {
...
}
var i: usize = 0;
while (i < 10) {
defer i += 1;
...
}
Honestly, I'm not sure why people think it is such a big deal. I've written a lot of zig, mostly gamedev stuff, and I rarely use that construction. I find that the vast majority of loops are over arrays or slices.
(The biggest thing I've hit that I want is a way to return information with an error. If that were fixed, I think Zig's error handling would be perfect.)
But the answer there is basically, "if you care about payload, don't use zig's built-in error handling." Which, obviously, you can do, but I'm not convinced it's a great answer!
Even for something as simple as parseInt, it would be nice, I would argue, if it returned, along with InvalidCharacter, which character was invalid. This would enable e.g. very precise indications in messages to the end user of what was wrong with the input.
In general, because currently it's super-ergonomic to return just error codes but more of a pain to return errors w/ payloads, what you'll get in practice is no error payload even when it would be useful, which will end up turning into less-helpful-than-ideal errors for end users, which is contrary to zig's goal of enabling the creation of perfect software. :-)
I found this thread interesting
Just thinking out loud, given Zig's errors primarily allow the compiler to enforce that errors are handled, and exhaustively, beyond that why can't error payloads just be passed as an input argument pointer to the function call? Maybe this is a dumb idea, but it's what C programs already do, except C programs don't have the safety of compiler checked errors offered by Zig. Does the Zig compiler need to check error payloads beyond the type system already provided? I'm not sure.
I agree with you that having such a super-ergonomic error handling system will direct most code towards a certain style, but I don't think this is contrary to Zig's goals of perfect software or simplicity. It's already such a huge win on top of C's error handling.
Yeah, that's definitely a reasonable way to do it, and actually Andrew gives an example of this:
https://github.com/ziglang/zig/issues/2647#issuecomment-5898...
(Andrew's example is slightly different in that rather than an explicit argument, it's an optional field in one of the arguments.)
So it's definitely not like crazy bad or anything, but also definitely less ergonomic than if you could directly return a payload with the error, and this is enough friction that it feels like you'll end up not having error information when you want it (both as an API consumer and eventually as an end-user looking at an error message).
But, I'm still very new to Zig, so perhaps my instincts on that are wrong. :-)
Maybe you're right too! Just speaking for myself here, but as a programmer and "man with a hammer", I sometimes like to think that instincts might just be our mental machine learning model, where it can be really well trained and give the right black box answer, albeit not with the explanatory backstory or rationale, but worth trusting nevertheless.
I'm also new to Zig, and there are ways that a pointer input arg as error payload could go wrong. I'm following the proposal issue, and it will be interesting to see which way it goes.
var it = a.getSomeIterable();
while (it.next()) |item| {
...
}
var it2 = b.getSomeIterable();
while (it2.next()) |item| {
...
} {
var it = a.getSomeIterable();
while (it.next()) |item| {
...
}
}
{
var it = b.getSomeIterable();
while (it.next()) |item| {
...
}
} get size
allocate slice
for(slice) |*elem| elem.* = read()In second case, it's "defer", coming from Go, the language which chickened out to add normal exceptions, because they're "implicit transfer of control", and LOLishly added "defer", as if it's not such.
They absolutely don't. All control paths are explicitly represented by syntax (no different from the hidden goto in a while loop -- it's explicitly recognised by the while syntax); proof: you can draw all of them by just examining the syntax of the current subroutine, while knowing nothing about others. Exceptions, however, are implicit: any call, foo(), might or might not cause some control flow change in the client without there being any explicit acknowledgement of that by the client; you cannot draw all the flow paths just by examining the syntax of the current subroutine.
res, exc = fun();
if (exc) goto exception_handler;
It's only C's syntax which is truly explicit. It's literally a structured machine-independent assembler. That's why it's gold language which is very hard to displace (it's already perfect for what it is). But just as everyone I'm watching with popcorn all the contenders popping up. (My humble opinion about Zig's issues on that path, I, together with other people, expressed here.)
Its implicitness is zero -- there is zero information not available in the syntax of the current block, exactly as in C -- so I don't see how it can be high compared to anything. You just don't have it in C, so you're not used to it. This is exactly like an Assembly programmer who says that C's `while` is implicit because there is no explicit jmp. In fact, the third clause in C's `for` header works almost exactly like defer: you write a piece of code that isn't executed immediately after the preceding one, but is injected to the end of the block.
A language with `while` isn't any more implicit than a language with just goto; it just has another explicit control-flow construct. Same goes for defer.
> It's literally a structured machine-independent assembler.
Not so much once you take the preprocessor into account.
> it's already perfect for what it is
I think that was true in 1970, not today. First, we know more. Second, we write much bigger programs. Third, "structured assembly" isn't as valuable as it was now that even machine code is "high level." This is not to say that C could be replaced everywhere, but I think, intertia aside, it could be replaced almost everywhere.
Ah, so your mind's window is single block, that what you bang on. You know, blocks can be long too. To the end of reading 1000-line block, you think that you know how it ends. But oops, you completely forgot about some "defer", which implicitly executes at the end of block. That's my definition of "true explicitness", where all code which executes at some point is available locally.
And if you forgo that definition of explicitness, why stop at block? Exceptions work across blocks, i.e. on the level of the entire subroutine, and not much harder to reason about than "defer".
> In fact, the third clause in C's `for` header works almost exactly like defer
Good point. It's a clause in "for", so best practice is to use it for "loop iteration expression". It's also familiar syntax to the entire generations of programmers. Unlike Zig's "2nd clause in while" which is "original design" people will "thank" you for.
> it could be replaced almost everywhere.
The question is with what. IMHO, Zig isn't good enough to replace C at all. Too much NIH, again. It does too much differently. Naive thinking is of course "so that it's better", but actually, it just repeats C's mistakes (ugliness in language) and makes its own, "very original" ones.
But no control flow construct satisfies that. Jumps are the whole point, and the unit for structured control flow is the block (what's the next instruction after `break`, `continue` or `}`?). defer is just as structured, just as local, and just as explicit as C's control flow constructs.
> It's also familiar syntax to the entire generations of programmers.
True, but learning Zig takes a day; two tops. Where it differs in syntax from C, it does so for good reason, and it's not like it's a complex language where different syntax is an additional burden. C's `for` syntax just doesn't make sense (`;`, which everywhere else in the language denotes sequential composition, means something different in the `for` header). Is an additional 2 minutes of learning, in a language that has very little syntax, not worth fixing something that's unpleasant in C?
Talk about confusing, implicit syntax of Zig - there's no connection between "it.next()" and "|item|". It's implicit and you need to make it up. Compare that to other languages: "for item in it" or "while (item = it.next())".
The for loop payload syntax, where you can also give a name to the counter, is the only weirdness with it.
I understand such a strategy (among many possible), and that will be a fun strategy if it pans out. The current situation though is that people question: why that dude purposely make it harder than needed for everyone?
Let's say `for (x in y) {}` replaced the payload operator. It would still exist in:
- if(some_error_union) |value| {} else |err| {}
- if(some_nullable) |value| {}
- while(some_nullable) |value| {}
- switch(some_tagged_union) { .some_tag => |value| {} }
And any that I might be forgetting. Is your suggestion that each of these should have separate syntax, thus complicating the language with one-off syntax?
I'm a human, and syntax is very important to me. 't broken read can syntax I. In that regard, if you purposely (or naively) misuse Comic Sans, then yes, "I don't like the font".
> (which IIRC was taken from Ruby or something).
Bingo. Ruby's not everyone's favorite language, so please be ready that people will send you rays of some hard love in that regard. Did you consider using C syntax for C-replacement-wannabe? (Rhetoric question.)
That's a valid reason to not want to use the language, but I don't believe it is a valid basis for criticism and certainly doesn't excuse the hostility of your comments in this thread.
I assume you mean a natural language. No, I won't complain about a real language used by people. I might criticize someone's inventing their own natural language. The same as I do for programming languages. And I'm very well familiar with the "we need to invent to move forward" argument. I also assume that people taking that ungrateful task are aware that they will receive criticism for that.
> just that it isn't the syntax you're used to.
Not just me, but many people. I specifically started to comment, seeing other people's feedback resonates with my own sentiment about Zig.
> certainly doesn't excuse the hostility of your comments in this thread.
I don't think there was particular "hostility", but I indeed try to nail right at the spot of the issues. Ouch! Beyond that, I allowed me some sour comments regarding downvoting other peoples' and my comments where concerns were raised with way Zig does some things. Such downvoting could be considered hostility, but I actually consider it funny ;-).
Let's look at some of your criticisms:
> @call(.{ .modifier = .never_inline }, collectNoInline, .{gc});
> /*pragma:noinline*/
> collectNoInline(gc);
Let's look at some more examples:
> Jumping thru hoops is what Zig seems to choose with its unorthodox, different-just-to-be-different syntax.
> Zig appears to have strong NIH mentality in regard to the syntax. Trying to replace C, but go out of their way trying to invent syntax just to be different from it and most other things too.
Zig's syntax isn't that unorthodox except compared to languages that look even more like C than it does, and it definitely isn't different just to be different. By claiming such, when there are thousands of posts in discussions about syntax, is plain insulting. Can you provide even a single post that suggests anyone has ever suggested syntax be a certain way just to be different?
Syntax is not irrelevant to the main use of a programming language the way fonts are to the use someone is probably concerned with if they ask an opinion of a screenplay, so, no, I don't see a similarity there.
> it took me less than a minute to understand the payload operator (which IIRC was taken from Ruby or something).
Loosely inspired by Ruby, perhaps, but definitely not taken from. Neither the positioning nor the semantics are the same.
That's just not true. It is not only pretty exceptional in its general partial evaluation construct combined with compile-time introspection (although D and Nim have some similar features), it is the only language AFAIK where a single general partial evaluation construct is used in stead of type generics, value generics, typeclasses/concepts, constexprs, macros and conditional compilation.
Zig might not be your cup of tea, and that's fine, but it is without a doubt unique in its design and not only special, but pretty radical.
> Talk about confusing, implicit syntax of Zig
I don't think it's any more confusing than any other syntax (and less confusing than C's `for` syntax where the ubiquitous `;` is treated differently than anywhere else), even though it might not be familiar to you before learning it, but there is absolutely nothing implicit here. You might find `in` more appealing to you or more familiar than `|` but it's certainly not more explicit.
There is an example here for a kind of iterator.