> Comparing to really-simple C, it's full of arcane stuff.
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.
> I think it's quite the opposite. Don't forget that C also has macros and a lot of arcane undefined behaviour.
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!
> C clearly needs a AST-based macros, not a whole new language to replace it.
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.
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.