Zig Goals(github.com)
github.com
Zig Goals
https://github.com/ziglang/zig/tree/4236b85c722b36cb31595634bae0ff28d6082761
53 comments
What I find remarkable is how closely aligned these goals are with the Zig we see today. Andrew is an incredible engineer and, while I don't prefer all of Zig's design decisions, he clearly had a very complete vision for the language from the beginning.
In more recent news, today Zig launched 0.13.0
https://news.ycombinator.com/item?id=40605828
https://news.ycombinator.com/item?id=40605828
You probably want (2015) in the title.
Kind of meh just linking to goals 9 years ago. How'd they pan out? 100%? 50%?
All of the listed goals have arguably been met, except:
- Auto-generating a `.h` file has temporarily regressed
- Friendly toward package maintainers is an ongoing goal
- "Memory zeroed by default" is not accurate, instead you must initialize all variables (to either some value or `undefined`)
- Auto-generating a `.h` file has temporarily regressed
- Friendly toward package maintainers is an ongoing goal
- "Memory zeroed by default" is not accurate, instead you must initialize all variables (to either some value or `undefined`)
FYI there's also std.mem.zeroInit(T), or std.mem.zeroes(T) for C-style zero-init
I wish I could pray and convince language author to please give us RAII in Zig. That is the only thing I want presently - I truly detest writing `defers` after my experience in Golang. If Zig wants trash cleanup absolutely explicit, then please at-least give us a C# like `using` or Python `with` statement. I will move to using Zig tomorrow and praise it to the heavens.
Do you mind explaining why defer is a problem in Go? I only have experience with Java’s try-with-resources which I like a lot, it looks like C# using is similar.
I’m not the commenter but I too am not a fan.
1. You cannot remotely easily wire them in a SIGINT scenario. I have done it, it was a load of plumbing and I wrote an equivalent to Java’s shutdown hook and tied it to sigterm and sigint then called that same hook in the normal shutdown path to simulate the defer call cycle.
2. “using” or “with” in other languages is nice and explicit about when it runs and you can easily run it before your function exits. In the case of go you need to wrap some function to force this same behavior in Go and it looks very forced.
Defer is fine, especially if you’re writing something with a simple life cycle. I just end up using it less when I need to support cleanup functions being called no matter what in a graceful shutdown.
1. You cannot remotely easily wire them in a SIGINT scenario. I have done it, it was a load of plumbing and I wrote an equivalent to Java’s shutdown hook and tied it to sigterm and sigint then called that same hook in the normal shutdown path to simulate the defer call cycle.
2. “using” or “with” in other languages is nice and explicit about when it runs and you can easily run it before your function exits. In the case of go you need to wrap some function to force this same behavior in Go and it looks very forced.
Defer is fine, especially if you’re writing something with a simple life cycle. I just end up using it less when I need to support cleanup functions being called no matter what in a graceful shutdown.
Linking to the README.md file directly instead of the source code tree would make the intent of this submission more obvious.
I agree. Below is the direct link in case one of the moderators see this and want to update.
https://github.com/ziglang/zig/blob/4236b85c722b36cb31595634...
https://github.com/ziglang/zig/blob/4236b85c722b36cb31595634...
The ability to export a zig project to a single C header file would be really nice. Is that still a planned feature?
Compiling to a single C file such that you can then compile the result via say clang is already supported (-ofmt=c). Automatic generation of C header files from your Zig library is WIP. The current recommend approach is to just write the C corresponding header files yourself, the issue mentions a couple of examples.
https://github.com/ziglang/zig/issues/9698#issuecomment-9747...
https://github.com/ziglang/zig/issues/9698#issuecomment-9747...
How they basically could not improve on tagged union enum types as you express them in C is to me one of the misses. Modeling data through effortless sum types is a requirement for me when picking up a modern language.
you're confused. zig had tagged unions since before 0.1.0.
[deleted]
I know, I'm saying they implementation they ended up with is terrible.
An earnest question: can you elaborate on what Zig got wrong in that respect?
I assume you mean algebraic data types as found in C#, Go (awkwardly), Rust, Swift, TypeScript, and Zig.
Also, gradual typing + ADTs: Crystal, Elixir and Erlang typespecs, Haskell, Python
Finally, dependent typing + ADTs: Ada 2012, Agda, Futhark, Idris, Lean
Also, gradual typing + ADTs: Crystal, Elixir and Erlang typespecs, Haskell, Python
Finally, dependent typing + ADTs: Ada 2012, Agda, Futhark, Idris, Lean
Since when does Go have algebraic data types? Like, even "awkwardly", I can think of nothing that even come close.
He might be referring to switching on the type of an interface... Not ADT for sure but I mean it's possible as a cludge as a tagged union, but it's more akin to single inheritance to be fair...
I don't think this was super important given the core goals of the project. I agree that effortless tagged unions are a very valuable feature in a language, but it's also one that is paradigm shifting and requires a different set of goals.
Without naming names, there is a language out there with some overlap with Zig's domain that does have really good tagged unions. But that project has a different set of goal than Zig's and that's okay. They're both good projects.
Without naming names, there is a language out there with some overlap with Zig's domain that does have really good tagged unions. But that project has a different set of goal than Zig's and that's okay. They're both good projects.
[deleted]
> Opinionated when it makes life easier.
> Tab character in source code is a compile error.
I don't think I will ever understand this. I get that different people have different preferences and reasons for those preferences, but why deliberately alienate such a large set of potential users? Especially after a statement asserting it's to make life easier? Who's life? The developers who will be using the language? I'm not convinced forcing all users to either type more white space or figure out how to configure their editor to auto convert (some of which may not be able to) is really making life easier. Or is it for the language developers themselves? In which case I'd argue that's probably the wrong thing to be optimizing for, and that it isn't that difficult to support both anyway.
And to be clear, I'm not interested in litigating the tabs vs spaces debate here, or even white space as part of code/syntax. It's this attitude that I'm seeing a lot more in recent years of 'I know better than you how you should do/use _X_ so I'm not going to give you the option'. Obviously not every project out there can be tailorable to every user's every preference, but I wish that when deciding what to accommodate and what not to, it would be done not on one's own myopic perception of the problem space, but on actual limitations and priorities and user needs. And when making a choice that may not be widely popular, be up front about why and how that decision was made. I'm much happier accepting 'not enough dev resources to support the added complexity in the parser' than I am 'tabs are stupid and you're dumb for wanting to use them'.
I don't think I will ever understand this. I get that different people have different preferences and reasons for those preferences, but why deliberately alienate such a large set of potential users? Especially after a statement asserting it's to make life easier? Who's life? The developers who will be using the language? I'm not convinced forcing all users to either type more white space or figure out how to configure their editor to auto convert (some of which may not be able to) is really making life easier. Or is it for the language developers themselves? In which case I'd argue that's probably the wrong thing to be optimizing for, and that it isn't that difficult to support both anyway.
And to be clear, I'm not interested in litigating the tabs vs spaces debate here, or even white space as part of code/syntax. It's this attitude that I'm seeing a lot more in recent years of 'I know better than you how you should do/use _X_ so I'm not going to give you the option'. Obviously not every project out there can be tailorable to every user's every preference, but I wish that when deciding what to accommodate and what not to, it would be done not on one's own myopic perception of the problem space, but on actual limitations and priorities and user needs. And when making a choice that may not be widely popular, be up front about why and how that decision was made. I'm much happier accepting 'not enough dev resources to support the added complexity in the parser' than I am 'tabs are stupid and you're dumb for wanting to use them'.
I think this is to avoid debate in the team that would use the language. The language simply doesn't allow that, end of discussion.
Just like `go fmt`. It's a compiler error for unformatted codes.
Just like `go fmt`. It's a compiler error for unformatted codes.
It doesn't avoid the debate; it just makes it take place when choosing the language.
Have you really seen language chosen based on formatting?
I've seen python rejected because of it
Indeed. I still hate Python space sensitive syntax after 2 years of working with it.
Indeed, that's the only reasonable scenario that comes to mind.
That is an opinionated decision to make tabs a compile error. It sounds like it offended you somehow, since nowhere does it even imply "tabs are stupid".
There could be a reasonable explanation, for example, that having two different characters for white space is redundant and unnecessary. We may not agree, but making it an error to use tabs is an effective way to avoid any bike shedding about this contentious topic.
It's similar to the Go formatter enforcing tabs for indentation and white space for alignment. It doesn't matter what I may think is the correct answer to the tabs/spaces question because I would never bother doing that manually. Either let some tool do it automatically, or don't allow tabs at all - which I'm guessing is how Zig's formatter works, by replacing tabs with white space.
There could be a reasonable explanation, for example, that having two different characters for white space is redundant and unnecessary. We may not agree, but making it an error to use tabs is an effective way to avoid any bike shedding about this contentious topic.
It's similar to the Go formatter enforcing tabs for indentation and white space for alignment. It doesn't matter what I may think is the correct answer to the tabs/spaces question because I would never bother doing that manually. Either let some tool do it automatically, or don't allow tabs at all - which I'm guessing is how Zig's formatter works, by replacing tabs with white space.
I also think these features are no good. I agree with you, I don't like this attitude of "I know better than you how you should do/use _X_ so I'm not going to give you the option" and the related stuff (and it is found in other computer programs too).
(In addition to the opinions about tabs, and about trailing spaces (which you did not mention, but it is related; when writing programs in C, I often have trailing spaces in incomplete programs), it also uses UTF-8.)
However, it might make sense to disallow tabs inside of string literals if you want "secure character set" (in which case disallowing trailing spaces inside of multi-line string literals also makes sense), but then you should not allow non-ASCII characters either (if you need non-ASCII text, it can either be escaped, or loaded from a separate file; the ability to run arbitrary code at compile-time would make this easy enough to do).
(Even then, it would probably make sense for "secure character set" to be an option (whether enabled or disabled by default) rather than mandatory, anyways.)
(In addition to the opinions about tabs, and about trailing spaces (which you did not mention, but it is related; when writing programs in C, I often have trailing spaces in incomplete programs), it also uses UTF-8.)
However, it might make sense to disallow tabs inside of string literals if you want "secure character set" (in which case disallowing trailing spaces inside of multi-line string literals also makes sense), but then you should not allow non-ASCII characters either (if you need non-ASCII text, it can either be escaped, or loaded from a separate file; the ability to run arbitrary code at compile-time would make this easy enough to do).
(Even then, it would probably make sense for "secure character set" to be an option (whether enabled or disabled by default) rather than mandatory, anyways.)
Consistency >> people's individual preferences when working in a large organization, which is how most stuff gets built.
If you are completely alienated from a language because of your white space preferences it’s probably a sign you need to re evaluate some priorities.
[deleted]
Maybe we need a version of Dlang based on Zig rather than C.
> Whitespace at the end of line is a compile error
How does this "make life easier"?
How does this "make life easier"?
One less annoyance for others to deal with.
Set your text editor to trim trailing whitespace on save, then I won't have to filter out your crap from my commits just because I happened to save a change in the same file that was previously saved by your sloppy text editor.
I wholeheartedly endorse this. While we're at it, please set your text editor to ensure that every file ends with a newline character.
Set your text editor to trim trailing whitespace on save, then I won't have to filter out your crap from my commits just because I happened to save a change in the same file that was previously saved by your sloppy text editor.
I wholeheartedly endorse this. While we're at it, please set your text editor to ensure that every file ends with a newline character.
Practically, engineers should never think about something like this because their environment should automatically fix it. I guess it's weird that it won't compile but there's languages that won't compile if you don't end the line with a semicolon. Just use an editor that will fix this automatically and never spare another thought for it.
So I can avoid needing to double check changes when I hit save on a file that you previously edited with white space and all of a sudden my one line change has 4 changed lines.
Off topic, but how stable is Zig's syntax these days?
From previous conversations, very stable. There shouldn't be any changes going into v1.0
Thanks, nice to know
Some of these look like good ideas. Some look like bad ideas:
> Tab character in source code is a compile error. Whitespace at the end of line is a compile error.
Both of these seem like bad ideas, except perhaps tab characters in string literals (or anywhere else that replacing it with an arbitrary number of spaces changes the meaning of the program) should be errors. Whitespace at the end of the line, also should not be an error unless deleting them would not change the meaning of the program. (Another reason to disallow tabs would be if indentation-sensitive syntax is used (like Python), although I dislike the indentation-sensitive syntax anyways.)
(Also, I often have spaces at the end of a line in incomplete programs I write in C; usually this will be eliminated if that part of the program is complete, though.)
> Source code is UTF-8.
Also bad. It is an unnecessary restriction, unless you want to use a "secure character set" (which should probably be an option and not mandatory, anyways), in which case it is an insufficient restriction (ASCII only (without most controls) would be better). If you do want the "secure character set", then the alternate restrictions for tabs and trailing spaces that I mentioned above, would help.
However, since you can run code at compile-time, if that allows reading other files in the same directory then you can put any non-ASCII text that you need, in other files, and then load them at compile-time. (This is much cleaner than the messy ways of having to deal with mixed text directions (and other stuff) in Unicode.)
> Ability to declare dependencies as Git URLS with commit locking (can provide a tag or sha1).
Providing a hash is helpful for security, although keeping a copy of the dependencies would also help, and you can access any copy of it; this way you do not need an internet connection (or even if you do, in case the connection is down, etc). Having multiple sources to find the dependencies is helpful, and if hashes are available for the files that it depends on then you can verify that it is the correct file.
> C style comments.
Depending on the syntax of what tokens would make sense together, it might not be the best idea (although this depends on what the syntax of Zig otherwise is; it might not be a problem). In C, a slash followed by an asterisk denotes the beginning of a block comment, but a slash also means division, and an asterisk as a unary operator denotes dereferencing; this is a sensible combination, so a space or parentheses or [0] or something else like that would be required in order to not be treated as a comment. This is a bad idea in C; I don't know enough about Zig to know how well it works in Zig, though.
> Shebang line OK so language can be used for "scripting" as well.
This is also something to be considered depending how the rest of the syntax works. It is probably a good idea though, if it does not interfere with other syntax like the comments in C interferes with the syntax of the operators in C.
> Tab character in source code is a compile error. Whitespace at the end of line is a compile error.
Both of these seem like bad ideas, except perhaps tab characters in string literals (or anywhere else that replacing it with an arbitrary number of spaces changes the meaning of the program) should be errors. Whitespace at the end of the line, also should not be an error unless deleting them would not change the meaning of the program. (Another reason to disallow tabs would be if indentation-sensitive syntax is used (like Python), although I dislike the indentation-sensitive syntax anyways.)
(Also, I often have spaces at the end of a line in incomplete programs I write in C; usually this will be eliminated if that part of the program is complete, though.)
> Source code is UTF-8.
Also bad. It is an unnecessary restriction, unless you want to use a "secure character set" (which should probably be an option and not mandatory, anyways), in which case it is an insufficient restriction (ASCII only (without most controls) would be better). If you do want the "secure character set", then the alternate restrictions for tabs and trailing spaces that I mentioned above, would help.
However, since you can run code at compile-time, if that allows reading other files in the same directory then you can put any non-ASCII text that you need, in other files, and then load them at compile-time. (This is much cleaner than the messy ways of having to deal with mixed text directions (and other stuff) in Unicode.)
> Ability to declare dependencies as Git URLS with commit locking (can provide a tag or sha1).
Providing a hash is helpful for security, although keeping a copy of the dependencies would also help, and you can access any copy of it; this way you do not need an internet connection (or even if you do, in case the connection is down, etc). Having multiple sources to find the dependencies is helpful, and if hashes are available for the files that it depends on then you can verify that it is the correct file.
> C style comments.
Depending on the syntax of what tokens would make sense together, it might not be the best idea (although this depends on what the syntax of Zig otherwise is; it might not be a problem). In C, a slash followed by an asterisk denotes the beginning of a block comment, but a slash also means division, and an asterisk as a unary operator denotes dereferencing; this is a sensible combination, so a space or parentheses or [0] or something else like that would be required in order to not be treated as a comment. This is a bad idea in C; I don't know enough about Zig to know how well it works in Zig, though.
> Shebang line OK so language can be used for "scripting" as well.
This is also something to be considered depending how the rest of the syntax works. It is probably a good idea though, if it does not interfere with other syntax like the comments in C interferes with the syntax of the operators in C.
[deleted]
Flagged, per observations confirming other comments noting old, unclear link, people noting they're not sure if they're on-topic, and multiple people downvoted below 0 when they use the link as a source for their comment.
Even with charity and steel-manning, this is a one-off, broad, short, personal todo list from 9 years ago.
That leads me to believe it is unclear what the topic is, and it is clear it is a minefield if you comments.
Even with charity and steel-manning, this is a one-off, broad, short, personal todo list from 9 years ago.
That leads me to believe it is unclear what the topic is, and it is clear it is a minefield if you comments.
[deleted]
Rust tooling however makes it an easy choice. Unit testing with pretty printing, proptest crate for property based testing, Cargo.toml is just an easier life choice than build.zig, etc etc.
Not sure if Zig will improve in this regard. I suspect what I consider an improvement Zig folks would not. Still easier to wrangle than C.