I know syntax does not REALLY matter, but Zig is just kind of subpar syntax wise. Its really verbose and picked weirdly from what already exists. Zig code is usually hard to read because it really noicy, and has weird things not existing in other languages without merit.
Well, compared to what? Zig is much nicer to read than Rust or C++, about the same as Typescript, but not as nice as modern C.
But that's just my opinion.
Such questions usually come down to "how familiar am I with this programming language", and anything that doesn't look like your pet language looks ugly. Except Rust and C++ of course, those are objectively ugly ;P
I'm not really against such special symbols, only if they are too much, like in Perl.
~ and @ weren't replaced by anything with ::, though, ~Foo is Box<Foo> and @Foo is Rc<Foo> (or is it Arc<Foo>?). :: to access a member of a module already existed when ~ and @ was in Rust.
Ofc it boils down to familiarity. But making a custom version of, say structs is just a weird design. The mainstream struct syntax is something everyone knows, and zig made all kinds of weird decisions around it. Same goes for @SpecialThing, looks like PHP to me. Multiline strings are also a weird addition. The list goes on.
But making a custom version of, say structs is just a weird design.
This I don't understand? Zig structs are pretty much the same as in any other language, except that the declaration can be more flexible by building the struct type via comptime code (e.g. how Zig does generics) - and Zig groups structs and namespaces under the same keyword (which hardly matters in practice though).
@SpecialThing
...not any weirder than `__builtin` keywords in Clang or GCC and at least in Zig it's obvious that anything starting with a `@` is a builtin, while in Clang/GCC the `__` is not explicitly reserved for builtins. ObjC also uses a leading `@` to separate ObjC keywords from regular C keywords. Agreed that the @-noise can get a bit excessive in Zig though (mainly because implicit casting is heavily restricted, at least compared to C).
Multiline strings are also a weird addition
AFAIK the 'weird' multiline syntax is for keeping the parser simple and fast. Multi-line-strings themselves are a good feature to have though.
In general, if Zig code starts to look too 'noisy', that's usually a sign that the code should be simplified.
I definitely don't agree with all design decisions in Zig, but the syntax is mostly fine (my main critique points are that Zig often tries to lean too much into 'design purity' than 'programmer convenience' and that parts of the stdlib are too 'object oriented'.
in Clang/GCC the `__` is not explicitly reserved for builtins
In fact in C identifiers starting with _ are reserved for the implementation (except for in local scope if the second character is not an underscore or capital letter).
I don't think that it's really subpar. It's just unusual compared to others. In and of itself it's very consistent. For instance there's `|capture|` for capturing all sort of things(errors, optionals, ...) in nearly all control flow constructs. `blk:` for naming blocks, `if`s, `switch`, and so on.
Have a look at this blog post:
https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html
|capture| hides an inconsistency that bugs me – everywhere else, assignment to a variable flows leftwards. |capture| is an unnatural rightwards assignment.
in general, I like zig syntax, but i find that it had very little regard to how the eye moves on the page. it’s jarring at times.
Although assignments as expressions in C are convenient, I don't think they make a ton of sense and find Zig's capture easier to read (easier to immediately see what's being evaluated)
I saw that article previously. Nearly all of the syntax seem to be in-house with little benefit. All the examples could just use some modern c-like thing.
Zig has benefits, like comptime, no hidden control flow, memory mngmt, cross compilation etc. But its syntax is just a mouthfull of wats, whys and wtfs.
I can forsee a compile to Zig languge popping up sometime soon.
Some people are actually interested in programming, coming and bleating about LLMs making all the finer points of it unimportant is as clueless as a manager coming here and telling us that syntax is unimportant because he has programmers for that crap.
If you don't care, don't go around in programming threads telling you how it doesn't matter anymore. It doesn't matter to you, because you prefer to be ignorant about the details of programming, and you have found tools that let you live in ignorance, good for you. But some of us do care, and are going to continue to do so.
My point isn't that what you are doing is pointless or that you shouldn't enjoy what you do but that it ultimately holds very little economic value especially as someone in charge of hiring developers, their experience is more valuable in the sphere of architectural design than expertise over syntax.
LLMs compile english to whatever code you want and it can write it better, faster and more efficiently than a human can over the long run. You might have an edge in shorter sprints but that gap is quickly reduced when LLMs simply learn and apply whatever optimization they find and it can continue to output without any diminishing returns and at fraction of what it takes to pay a human to do it.
With LLMs you pay per token, so if you can express the same code in 1 / 10th the tokens that absolutely matters. Moreover they have a finite context window, so more concise syntax can make that more economical.
Sure but how many devs can sustain that level of efficiency around the clock and how much thought do you think their employers will give when the LLM tokens pay 1/100~1/1000th of the wage paid
I want code that is efficient, secure and cheap to produce. There is no way a human can compete with a network of agents doing that. Whatever edge you think exists is on a downward trend. Look at where we were in the days of GPT 4o vs now in terms of coding capability. Look at the marketplace for overseas contractors and the impact AI has had.
To ship what I do now would've cost a few million dollars per year in terms of the team needed to maintain it now its 1000x cheaper
I'm not making that argument are you responding to the right person?
My argument was that syntax still matters because LLMs communicate in syntax, and they pay for that per token, therefore LLMs make syntax more relevent as you can actually calculate cost to write in one language versus another.
I'm not arguing that humans can compete with a network of agents.
Comments
I know syntax does not REALLY matter, but Zig is just kind of subpar syntax wise. Its really verbose and picked weirdly from what already exists. Zig code is usually hard to read because it really noicy, and has weird things not existing in other languages without merit.
Well, compared to what? Zig is much nicer to read than Rust or C++, about the same as Typescript, but not as nice as modern C.
But that's just my opinion.
Such questions usually come down to "how familiar am I with this programming language", and anything that doesn't look like your pet language looks ugly. Except Rust and C++ of course, those are objectively ugly ;P
Early Rust was a lot more readable as well. Somehow it turned into the perl 6 of systems languages. They crammed everything they could in there.
Weird thing to say when early Rust had sigils everywhere.
Early Rust had ~ and @ references.
Which, IMO, read nicer than words and ::s drowning out names.
I'm not really against such special symbols, only if they are too much, like in Perl.
~ and @ weren't replaced by anything with ::, though, ~Foo is Box<Foo> and @Foo is Rc<Foo> (or is it Arc<Foo>?). :: to access a member of a module already existed when ~ and @ was in Rust.
Custom syntax highlighting / theming to emphasize names vs. qualifiers is very helpful.
Favorite comment of the day; you do know it will get downvoted to crap right?
Probably because this is a post about Zig’s threaded IO, and complaints about Rust syntax is two conversational leaps away from that subject!
Maybe I'm living in my own bubble, but I feel like criticizing Rust has become a little more acceptable recently.
Ofc it boils down to familiarity. But making a custom version of, say structs is just a weird design. The mainstream struct syntax is something everyone knows, and zig made all kinds of weird decisions around it. Same goes for @SpecialThing, looks like PHP to me. Multiline strings are also a weird addition. The list goes on.
This I don't understand? Zig structs are pretty much the same as in any other language, except that the declaration can be more flexible by building the struct type via comptime code (e.g. how Zig does generics) - and Zig groups structs and namespaces under the same keyword (which hardly matters in practice though).
...not any weirder than `__builtin` keywords in Clang or GCC and at least in Zig it's obvious that anything starting with a `@` is a builtin, while in Clang/GCC the `__` is not explicitly reserved for builtins. ObjC also uses a leading `@` to separate ObjC keywords from regular C keywords. Agreed that the @-noise can get a bit excessive in Zig though (mainly because implicit casting is heavily restricted, at least compared to C).
AFAIK the 'weird' multiline syntax is for keeping the parser simple and fast. Multi-line-strings themselves are a good feature to have though.
In general, if Zig code starts to look too 'noisy', that's usually a sign that the code should be simplified.
I definitely don't agree with all design decisions in Zig, but the syntax is mostly fine (my main critique points are that Zig often tries to lean too much into 'design purity' than 'programmer convenience' and that parts of the stdlib are too 'object oriented'.
In fact in C identifiers starting with _ are reserved for the implementation (except for in local scope if the second character is not an underscore or capital letter).
I don't think that it's really subpar. It's just unusual compared to others. In and of itself it's very consistent. For instance there's `|capture|` for capturing all sort of things(errors, optionals, ...) in nearly all control flow constructs. `blk:` for naming blocks, `if`s, `switch`, and so on. Have a look at this blog post: https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html
|capture| hides an inconsistency that bugs me – everywhere else, assignment to a variable flows leftwards. |capture| is an unnatural rightwards assignment.
in general, I like zig syntax, but i find that it had very little regard to how the eye moves on the page. it’s jarring at times.
But the capture is conditional so it makes sense.
if (evaluation) result = evaluation
if (evaluation) |result|
Although assignments as expressions in C are convenient, I don't think they make a ton of sense and find Zig's capture easier to read (easier to immediately see what's being evaluated)
if |result| (evaluation)
I think you could argue for it both ways. Then you could claim ternaries are inconsistent too, shouldn't it be:
resultA : resultB ? (evaluation)
if we always put result first?
I think the most important piece of if statements and ternaries is the condition being evaluated and it's worth putting that first?
but zig has no ternaries, so it does not apply to a discussion about zig’s syntax.
and ternary is a branch with no variable introduction, so it doesn’t apply again.
(it’s basically a weak switch expression, and the value moves leftwards towards its invocation.)
I saw that article previously. Nearly all of the syntax seem to be in-house with little benefit. All the examples could just use some modern c-like thing.
Zig has benefits, like comptime, no hidden control flow, memory mngmt, cross compilation etc. But its syntax is just a mouthfull of wats, whys and wtfs.
I can forsee a compile to Zig languge popping up sometime soon.
You might be interested in this recent talk which argues concrete syntax does actually matter: https://slim.computer/concrete-syntax/
Of course syntax matters in any programming language. That is like saying the alphabet and grammar does not really matter in English.
with LLMs? syntax doesn't really matter anymore exactly because of what you mentioned in your last sentence.
Some people are actually interested in programming, coming and bleating about LLMs making all the finer points of it unimportant is as clueless as a manager coming here and telling us that syntax is unimportant because he has programmers for that crap.
If you don't care, don't go around in programming threads telling you how it doesn't matter anymore. It doesn't matter to you, because you prefer to be ignorant about the details of programming, and you have found tools that let you live in ignorance, good for you. But some of us do care, and are going to continue to do so.
My point isn't that what you are doing is pointless or that you shouldn't enjoy what you do but that it ultimately holds very little economic value especially as someone in charge of hiring developers, their experience is more valuable in the sphere of architectural design than expertise over syntax.
LLMs compile english to whatever code you want and it can write it better, faster and more efficiently than a human can over the long run. You might have an edge in shorter sprints but that gap is quickly reduced when LLMs simply learn and apply whatever optimization they find and it can continue to output without any diminishing returns and at fraction of what it takes to pay a human to do it.
If you do not even read code (the fact that you don't write any is clear), then what do you do?
With LLMs you pay per token, so if you can express the same code in 1 / 10th the tokens that absolutely matters. Moreover they have a finite context window, so more concise syntax can make that more economical.
Sure but how many devs can sustain that level of efficiency around the clock and how much thought do you think their employers will give when the LLM tokens pay 1/100~1/1000th of the wage paid
Wdym, the LLM is writing it either way? My point is all else being equal, you’d prefer the code that’s shorter for the reasons stated.
I want code that is efficient, secure and cheap to produce. There is no way a human can compete with a network of agents doing that. Whatever edge you think exists is on a downward trend. Look at where we were in the days of GPT 4o vs now in terms of coding capability. Look at the marketplace for overseas contractors and the impact AI has had.
To ship what I do now would've cost a few million dollars per year in terms of the team needed to maintain it now its 1000x cheaper
I'm not making that argument are you responding to the right person?
My argument was that syntax still matters because LLMs communicate in syntax, and they pay for that per token, therefore LLMs make syntax more relevent as you can actually calculate cost to write in one language versus another.
I'm not arguing that humans can compete with a network of agents.
It does if you actually want to understand what the slop-bot is doing.