Zig Goals

https://github.com/ziglang/zig/tree/4236b85c722b36cb31595634bae0ff28d6082761

by whatever3 • 2 years ago

90 48 2 years ago

github.com

fallingsquirrel• 2 years ago

You probably want (2015) in the title.

nick238• 2 years ago

Kind of meh just linking to goals 9 years ago. How'd they pan out? 100%? 50%?

squeek502• 2 years ago

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`)

sekao• 2 years ago

The ability to export a zig project to a single C header file would be really nice. Is that still a planned feature?

frankjr• 2 years ago

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...

boricj• 2 years ago

Linking to the README.md file directly instead of the source code tree would make the intent of this submission more obvious.

thangngoc893• 2 years ago

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...

tiffanyh• 2 years ago

In more recent news, today Zig launched 0.13.0

https://news.ycombinator.com/item?id=40605828

durandal12• 2 years ago

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.

AndyKelley• 2 years ago

you're confused. zig had tagged unions since before 0.1.0.

durandal12• 2 years ago

I know, I'm saying they implementation they ended up with is terrible.

taliesinb• 2 years ago

An earnest question: can you elaborate on what Zig got wrong in that respect?

quocanh• 2 years ago

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.

hi-v-rocknroll• 2 years ago

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

TwentyPosts• 2 years ago

Since when does Go have algebraic data types? Like, even "awkwardly", I can think of nothing that even come close.

heavyset_go2• 2 years ago

Off topic, but how stable is Zig's syntax these days?

PartiallyTyped• 2 years ago

From previous conversations, very stable. There shouldn't be any changes going into v1.0

heavyset_go2• 2 years ago

Thanks, nice to know

refulgentis• 2 years ago

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.

0x0203• 2 years ago

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'.

xxpor• 2 years ago

Consistency >> people's individual preferences when working in a large organization, which is how most stuff gets built.

thangngoc893• 2 years ago

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.

EPWN3D• 2 years ago

It doesn't avoid the debate; it just makes it take place when choosing the language.

WD-422• 2 years ago

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.

smrq• 2 years ago

Spaces instead of tabs are an accessibility problem for some people. Being able to read and write source code is priority #1.

timacles• 2 years ago

Especially for the elimination of tabs

lioeters• 2 years ago

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.

zzo38computer2• 2 years ago

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.)

unclad5968• 2 years ago

Whitespace at the end of line is a compile error

How does this "make life easier"?

arcanemachiner• 2 years ago

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.

__loam• 2 years ago

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.

WD-422• 2 years ago

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.

ForLoveOfCats• 2 years ago

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.

LAC-Tech• 2 years ago

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.

lenkite• 2 years ago

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.

jcaguilar2• 2 years ago

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.

throwaway_qiwuw• 2 years ago

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.

fithisux• 2 years ago

Maybe we need a version of Dlang based on Zig rather than C.

zzo38computer2• 2 years ago

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.

Zig Goals

Related Stories