I like Zig the language. Probably more than rust - Zigs singular focus on making systems programming ergonomic really appeals to me.
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.
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.
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.
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.
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.
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.
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.
> 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'.
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.
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.)
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.
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.
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.
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.