Use of the pub keyword means you can tell whether a function is public in the module without needing to look at a separate place for listing exports (like, say, a header file). Though that itself has tradeoffs, so it's hard to say whether one or the other is better.
Use of the fn keyword makes it easy to find function definitions by grepping for it, whereas finding functions in regular C syntax needs semantic awareness.
What I don't understand is the !void at the end of the declaration, if we're meant to be returning an int, surely !int would be the expected syntax (although I would prefer returns int instead).
> What I don't understand is the !void at the end of the declaration, if we're meant to be returning an int, surely !int would be the expected syntax (although I would prefer returns int instead).
`!void` means the function can return an error (e.g. return error.BadArgument) but doesn't produce any value itself. In the case of an error in the main function, the process will exit with 1, otherwise 0. The main function can also return a value directly (return type u8 / !u8).
> In the case of an error in the main function, the process will exit with 1, otherwise 0. The main function can also return a value directly (return type u8 / !u8).
We know that by convention, but how do we know that from
No, the main function (the entry point of the entire program) is special cased. Have a look at the source code. There you can see it's calling the user defined main function and handling its return value / error.
You can access argv with std.os.argv which is a slice of null terminated strings. It's better to go with std.process.argsAlloc though (requires an allocation but works on all supported platforms).
In Zig, the main function can return either a u8 or void (which always returns 0) or it can return an error union !void, where if you allow an error to bubble up to main, it'll print an error trace and return 1.
> Use of the fn keyword makes it easy to find function definitions by grepping for it, whereas finding functions in regular C syntax needs semantic awareness.
does it matter though, in 2024 and beyond?
we've got clangd and lsp, grepping for functions is dumb, whether you're grepping C or grepping Zig.
We've had Ctags since 1992, so being able to grep for functions hasn't been important for 32 years... but there's still people who prefer to use grep to look for functions, so having a specific keyword is beneficial for them. It may also make the lex/parse/generate cycle simpler, but I'm not a compiler engineer, so I don't know for certain whether it does.
If you have a lot of experience with C, and take just a glance at the basics of Zig, I think you’ll understand why each of those changes were made. C doesn’t have very good syntax. Nether for compiler (correctly interpreting the code requires a lot of context), nor code editor, nor for humans.
If you have experience with some modern languages, you’ll definitely understand the syntax. Zig is close to a style of syntax that many newer languages seem to have settled on, and there are good reasons why that style has become prefer.
Why make a new language if you’re not going to make some improvements over the old? Seems like a very weird complaint to me.
What is the benefit of changing
int main(void) {
to:
pub fn main() !void {
Except making it looks like a "new" language and requires other people spends 15min to get to used to it？
There are tradeoffs:
Use of the pub keyword means you can tell whether a function is public in the module without needing to look at a separate place for listing exports (like, say, a header file). Though that itself has tradeoffs, so it's hard to say whether one or the other is better.
Use of the fn keyword makes it easy to find function definitions by grepping for it, whereas finding functions in regular C syntax needs semantic awareness.
What I don't understand is the !void at the end of the declaration, if we're meant to be returning an int, surely !int would be the expected syntax (although I would prefer returns int instead).
> What I don't understand is the !void at the end of the declaration, if we're meant to be returning an int, surely !int would be the expected syntax (although I would prefer returns int instead).
`!void` means the function can return an error (e.g. return error.BadArgument) but doesn't produce any value itself. In the case of an error in the main function, the process will exit with 1, otherwise 0. The main function can also return a value directly (return type u8 / !u8).
> In the case of an error in the main function, the process will exit with 1, otherwise 0. The main function can also return a value directly (return type u8 / !u8).
We know that by convention, but how do we know that from
If if write will that function also get to return a u8?Also, what happened to argv/argc?
> will that function also get to return a u8?
No, the main function (the entry point of the entire program) is special cased. Have a look at the source code. There you can see it's calling the user defined main function and handling its return value / error.
https://github.com/ziglang/zig/blob/2d888a8e639856e8cb6e4c6f...
> Also, what happened to argv/argc?
You can access argv with std.os.argv which is a slice of null terminated strings. It's better to go with std.process.argsAlloc though (requires an allocation but works on all supported platforms).
In Zig, the main function can return either a u8 or void (which always returns 0) or it can return an error union !void, where if you allow an error to bubble up to main, it'll print an error trace and return 1.
https://ziglang.org/documentation/0.13.0/#Hello-World
> Use of the fn keyword makes it easy to find function definitions by grepping for it, whereas finding functions in regular C syntax needs semantic awareness.
does it matter though, in 2024 and beyond?
we've got clangd and lsp, grepping for functions is dumb, whether you're grepping C or grepping Zig.
We've had Ctags since 1992, so being able to grep for functions hasn't been important for 32 years... but there's still people who prefer to use grep to look for functions, so having a specific keyword is beneficial for them. It may also make the lex/parse/generate cycle simpler, but I'm not a compiler engineer, so I don't know for certain whether it does.
We had ctags for lack of better alternatives, not because it’s any good
lsp can be extremely slow, on constrained devices
C's function declaration syntax is pretty weird and makes the language harder to parse. Most languages have a function keyword.
If you have a lot of experience with C, and take just a glance at the basics of Zig, I think you’ll understand why each of those changes were made. C doesn’t have very good syntax. Nether for compiler (correctly interpreting the code requires a lot of context), nor code editor, nor for humans.
If you have experience with some modern languages, you’ll definitely understand the syntax. Zig is close to a style of syntax that many newer languages seem to have settled on, and there are good reasons why that style has become prefer.
Why make a new language if you’re not going to make some improvements over the old? Seems like a very weird complaint to me.
Probably not much, but this is not the only change the language brings.
As someone who wrote C for my hobby projects, I've switched to Zig and enjoy it more as it feels I can express my intention more clearly
I'd go with for loop syntax:
15 minutes… the horror.
Are you saying you don't like isomorphisms?
What's the performance like compared to C? Is it faster to compile and almost as fast programs?
Apparently unsafe zig can be faster, but only due to unsafe rust being difficult to write in the style of pointers: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
What's the Zag gonna be?
A Smalltalk VM: https://github.com/Zag-Research/Zag-Smalltalk
I like vlang.io better...