Failing to Learn Zig via Advent of Code

https://www.forrestthewoods.com/blog/failing-to-learn-zig-via-advent-of-code/

239 329 5 years ago

Comevius6• 5 years ago

I see what went wrong here. You tried to lean on documentation and Google, you should have just go for the source code. It's quite readable, and it's the recommended way to learn for now. Zig has a few peculiarities, it's not stable yet, you kind of have to follow it's development.

https://github.com/ziglang/zig/tree/master/lib/std

coldtea2• 5 years ago

I see what went wrong here. You tried to lean on documentation and Google, you should have just go for the source code.

That sounds rather like a different thing was wrong - not where the author tried to lean: Zig has crap documentation.

bollu• 5 years ago

Zig documentation isn't crap; the documentation *does not exist* yet. There's an important difference between the two which seems to be ignored.

Zig is young. They're spending their time maturing the core ecosystem --- the compiler, the standard library, and so forth. It's perfectly reasonable to expect early adopters to "RTFS/read the fucking source". *When* they start writing documentation, I'd be perfectly happy to hear comments like "The zig documentation is crap".

At this stage of the project, I'll be honest, I find it upsetting to read comments like this.

meheleventyone3• 5 years ago

Yeah I did AoC a few years ago in Zig and found sticking the std path in my project so I could quickly search it was the best tool to figuring out how to do various bits and pieces.

rhodysurf• 5 years ago

I did the same! Cuz at the time there was no language server available beyond syntax highlighting and linting. But now there is a pretty good language server package available which is really helpful giving autocompleting

andi9992• 5 years ago

Recommended way to learn for now? Any sources for that?

delphLonepaw7• 5 years ago

Read the language reference, use ziglings, use ziglearn.org, use zls (don't trust it too much tho, but it will help a bit) and vscode or any text editor that supports jumping to the source, and of course, RTFS

ofrzeta• 5 years ago

My biggest failure was a poor decision to solve all Advent of Code puzzles in both Rust and Zig.

That's a bit overambitious maybe.

skywal_l• 5 years ago

Yes, error messages in zig needs improving but that's not surprising. Rust error messages where pretty terrible back in the day.

I found zig language reference pretty good[0]. It is simple, lot of example. I would find 80% on there and had to google the rest. And as another commenter said, looking at zig source code is actually not a bad idea. The std lib is pretty clear and with comments.

My biggest beef with zig is a lack of a package manager. But apparently, it is high in the list of priority for the author so...

[0] https://ziglang.org/documentation/master/

nkozyra• 5 years ago

I think zigs documentation is wonderful and explains most seemingly esoteric syntax and language options really well.

But if you hit a roadblock it's hard to track down more info. Some of that is due to the lack of adoption, though.

the_duke2• 5 years ago

A potentially huge roadblock to better error messages is lack of generics and interfaces/traits/classes.

The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors.

It'll be interesting to see how this plays out as the ecosystem grows.

naasking2• 5 years ago

The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors.

Why do you think that's the case?

p0nce• 5 years ago

Such usability reports are super informative for when you want to make software usable.

izhak• 5 years ago

It starts with a mention of hating Python and continues into a detailed report that could be alternatively called “100 wrong things that Python got right”

keyle• 5 years ago

I appreciate the honesty and thoroughness that the author is displaying here.

There are too many posts that focus on successes and embellish the state of affairs.

That said nothing was too surprising about a language that hasn't hit 1.0 yet.

brabel2• 5 years ago

Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced.

But I take issue with this:

    // Obviously good and easy to read
    return a*(1.0-t) + b*t;

    // Obviously bad and hard to read
    return add(mul(a, 1.0 - t), mul(b, t));

Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad).

Here's what I would consider obviously good :) for the objective reason that it does not require difficult to track implicit rules about operator precedence:

    1, - t, * a, + (t, * b)

I invented this syntax myself :) but it's extremely obvious once you know how it works.

It should be clear that this is similar to concatenative languages, where you push values onto a stack then apply operations on the stack. The `,` is used for pushing to the stack, basically. But then, it also allows you to "mix" more standard function notation into it... so when you write `a b` that means calling the `a` function with `b` as an argument (think LISP).

Now putting everything together

    1, - t

Should read as `1 minus t` as `- t` is the function `-` being called with one value from the stack, `1`, and one from the "function call" (as if it was LISP `(- 1 t)`).

    1, - t, * a

Reads as "1 minus t times a" and has no ambiguity: the result of `1, - t` is the first argument to ``, the second argument is `a`, so you get LISP's `( (- 1 t) a)` but reads much more naturally.

Finally, at the end, for readability, we use parens to group the final part of the equation:

    1, - t, * a,  + (t,  * b)

Hopefully it's obvious what happens now?

Does anyone like this form of expression or is just me? I tried to mix the best of LISP with the best of FORTH :) and I really like this.

rak15072• 5 years ago

I think there's a compromise between being recognisable as a mathematical formula and removing operator precedence which is what APL and other array languages do. (a×1-t)+b×t is how you'd write it in APL, no operator precedence but still more familiar.

user-the-name2• 5 years ago

That absolutely breaks the law of least astonishment. It's worse to look familiar but have hidden differences than to just look completely different.

littlestymaar• 5 years ago

Sorry, but the first one is not obviously good, it's just what you're used to.

That's also what everybody who as been in primary school is used to. Infix notation have its quirks but at least its ubiquitous.

ReleaseCandidat11• 5 years ago

That's also what everybody who as been in primary school is used to.

That would (hopefully ;) have been

   (1 - t)a + tb

alexvoda• 5 years ago

The notation the author complains about looks like a broken polish (prefix) notation with added parens.

Your notation looks like a very bizare mix of infix arrangement postfix (RPN) behaviour plus added parens for good measure.

RPN has plenty of benefits, once you get used to its initial awkwardness, that I feel your notation fails to capitalise on.

ReleaseCandidat11• 5 years ago

The notation the author complains about looks like a broken polish (prefix) notation with added parens.

The notation the author complains about is the first version using 'normal' (prefix) functions.

    a + b = (+)(a, b) = add(a, b) = a `add` b (Haskell infix) = a .add. b (Fortran infix)
    a * b = (*)(a, b) = mul(a, b) = a `mul` b = a .mul. b

  a*(1.0-t) + b*t

  (+)(a*(1.0-t), b*t) = (+)((*)(a, 1.0-t), (*)(b, t)) = add(mul(a, 1.0-t), mul(b, t))

thom5• 5 years ago

The LISP version can be more readable with (e.g. Clojure’s) threading macros:

    (-> 1
        (- t)
        (* a)
        (+ (* t b)))

Obviously use more or less whitespace to taste.

user-the-name2• 5 years ago

I can not read that at all.

Jach2• 5 years ago

The Lisp version can also be more readable with a macro (like https://github.com/quil-lang/cmu-infix): #I(a*(1.0-t) + b*t). Or something else that would let you write GP's preferred syntax. One of the things that makes Lisp Lisp is that if the parens are over-cumbersome, you have the tools to take them away. See also CL:LOOP.

brabel2• 5 years ago

This is almost equivalent to my proposed syntax, just replace `->` with commas between each term (minus the parens)!

edflsafoiewq3• 5 years ago

A notation which everyone is already used to is obviously good. A very compelling benefit is needed to outweigh "you already understand this".

Zababa6• 5 years ago

(a * (1 - t)) + (b * t) would be my favorite way to express this in a programming context, I don't really see the point of your proposition over prefix or stack:

    (+ (* a (- 1 t)) (* b t))

    1 t - a * b t * +

nemothekid• 5 years ago

Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad).

The first one is good because its what most people are used too - there's little that can be objectively said about notation once you reach a big enough audience. I could invent a word editor that produced documents from top to bottom rather then left to right and I could invent a million reasons what it's better, but that hardly matters.

Personally I don't think Polish notation is all that revolutionary for humans, it's just easier for computers; however just like anything else the human brain is quite malleable, and if you spend a year doing equations in polish notation you will come to prefer it.

kazinator• 5 years ago

It has been proposed to me (just yesterday!) by a collaborator to ad a linear interpolation function to TXR Lisp, so that would look like:

  (lerp t a b)  ;; possibly, modulo argument order.

ffhhj2• 5 years ago

Rust is trying to be a better C++
Zig is trying to be a better C

I recently started learning Rust by adding snippets to The Quick Snippet Reference [0]. Without any previous knowledge of the language I knew there had to exist a data type for dynamic arrays. After several Stack Overflow searches I found it: Vec. It was very interesting to compare to Python's Array. Getting to understand the drain() method was a refreshing experience. I'm still hesitating about the best way to handle errors (Rust has no exceptions, just panic!), but that will probably become clearer when working with threads. And Rust compiler's warnings and errors are really nice. I'll certainly give Zig a try.

[0] https://github.com/snippetfinder/The-Quick-Snippet-Reference

pyjarrett• 5 years ago

How is this different from Rosetta Code? (https://rosettacode.org/wiki/Rosetta_Code)

ffhhj2• 5 years ago

How is this different from Rosetta Code?

Yeah in some way they are the same kind of reference. I already knew about Rosetta Code, explored their snippets and found them valuable as a learning tool by curiosity. But The Quick Snippet Reference presents examples to do the smallest tasks that we would need when programming. The tree of these minimal operations is shared between languages, so it's easier to compare, or find how to do something in a new language that you already use in another.

tialaramex12• 5 years ago

The important decision about an error is:

Should I cope with this? If so, do so. This is likely if you're a library and unlikely in some application software, especially AoC. Don't ask me to try calling fooA() and then call fooB() if it fails, just have that code inside fooA() already.

If not, might my caller want to know what went wrong? In a library your users might want to cope, unless you're sure the situation is fatal and all hope is lost, so always return Result and use appropriate Errors for error cases, the ? operator can help you pass on errors from other libraries.

Otherwise panic.

Because Rust's Result doesn't change control flow, you don't need to decide how callers should cope with Errors, only flag that it's their problem not yours. Because Result doesn't have a non-Error result in it if you returned an Error, your caller can't mistakenly carry on anyway, they'll just panic if they try to do that.

AnIdiotOnTheNet3• 5 years ago

As a seasoned Zig programmer, this is good information, though painful to read. A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation.

I also have to wonder about a fundamental misalignment of thinking when someone says downloading and replacing a single .exe is tedious, and isn't at all excited about 'Why Zig' list. If none of those things seem like compelling ideas to you then yeah, the language probably isn't for you.

SiVal• 5 years ago

If there are fundamental philosophies in a programming language (and there usually are), tutorials ought to begin with lots of tiny example programs that exemplify those fundamentals. They should continue with examples of gradually increasing complexity, but ALWAYS using those same fundamentals in various combinations to show how those fundamentals are intended to work together in all sorts of ways.

If the tutorials aren't deliberately built up from the language's own defining philosophical fundamentals introduced singly and then in combination, then someone like me will just re-use the fundamentals I learned in whatever other languages I know that feel most similar to the new one. Most languages can be used in roughly parallel ways with just a change in syntax, even if that's not how they are supposed to be used, and if I (like most of us) have to get up and running ASAP in some new tool and don't have a quick on-ramp to establish the preferred patterns right from the start, I'll just have to re-use as much as I already know and just get on with it.

llimllib3• 5 years ago

My understanding of the Zig's team's opinion is that Zig is not currently at a place where they want to solidify the design by doing such things as writing extensive tutorials documenting how to write it - tutorials that will need to be updated every time they make breaking changes, which they explicitly still want to do.

A lot of this seems to be a mismatch between people's expectations of zig's stability and the reality?

jibalt20• 5 years ago

You're talking about idioms, not philosophy ... the philosophy of Zig can be obtained by running `zig zen`. And the OP didn't even read the Hello World section of the Zig Reference Manual that has an example of printing.

dnautics10• 5 years ago

Nah, I think it is fine. The problems are almost all (the author's) problems with zig's philosophy of "when to do things you need for a 1.0". Author mostly wants docs, guides, error messages, and package manager, which are supposed to be "late in the development process" according to my understanding of the unofficial zig roadmap.

jibalt20• 5 years ago

The author didn't even read the Hello World section of the Zig Reference Manual that (of course) has an example of printing.

mst11• 5 years ago

I have a feeling that Zig is sufficiently different to most other languages in the space that developing a mental model for the way things are supposed to fit together is something that involves "aha" moments - the sort that are tricky to produce for everybody via a single piece of documentation because the thing that makes it snap together in a particular person's head varies widely between people.

Similar to the process of getting the concepts of git when you've come from other version control systems.

(I have a horrible feeling that the solution to this is mostly going to be "lots of people writing tutorials that approach it in different ways until there's at least one tutorial out there that will work for (most values of) any given person", and having been there on projects of mine I sympathise with the unsatisfyingness of this conclusion)

jibalt20• 5 years ago

When I saw the first line of some Zig code, it was unusual so I thought about it and got an inkling of the idea behind it and its power:

const std = @import("std");

When I saw the second line and subsequent similar lines, I realized it was effing brilliant:

const os = std.os;

std and os here are names bound to types ... and you can have type variables and do compile-time manipulation and construction of types. This is confirmed in the manual when it talks about generic types being the return values of functions executed at compile time that take types (and/or other comptime values) as arguments -- while C++ templates are purportedly Turing complete, this is far more powerful in practice because it's vastly easier and more straightforward. Looking at code in the library like MultiArrayList--which implements AoS (array of structures) in the library rather than in the language--further confirms this.

So what's going on with those `std` and `os` bindings? The answer is given at the beginning of the Zig Language Reference (https://ziglang.org/documentation/master/) (which the OP apparently didn't read since it has a Hello World program that is an example of how to print): "The @import("std") function call creates a structure that represents the Zig Standard Library". So essentially, every source file represents an anonymous struct (all Zig structs are anonymous), the members of which are the top level declarations in the file--or rather, @import(filename) presents the file as such a struct, which can be assigned to a type variable like `std`. And `std.os` is in turn a type variable whose value is @import("os.zig") ... except that the actual value of `std.os` is computed based on the target machine. By turning files into comptime data structures containing all of the file's top level declarations, and having Zig code executable at comptime, immense power is achieved and one of the consequences of this is that zig running on any host is a complete cross compiler that can generate code for any target, using an appropriate target-specific version of the library. And it only took me a little bit of reading of docs and code to get my "aha" about how this works.

thayne• 5 years ago

The biggest thing that stands out to me from the complaints is the lack of documentation, which is probably part of the misunderstanding of the philosophy.

jibalt20• 5 years ago

A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation.

As a rank beginner, I had no problem learning these things ... they're mentioned repeatedly in material about Zig both from the project and from outside descriptions, the philosophy is the output of `zig zen` and in all the documentation, etc. The OP couldn't figure out how to print despite the Hello World program at the beginning of the Zig Reference Manual. I think most of the issues here are PEBKAC.

NeutralForest• 5 years ago

I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a tool or a small to medium library is fine, it's not fine for large projects or projects you know nothing about.

Incremental examples is where it's at. You should document a fonction/type/feature/whatever with a short example with basic operations and then a more involved example with good practices and potential caveats. I know this is a lot of work, I understand it can't be like that everywhere.

This is not a dig at anyone's project or language, but "read the source code" comments always strike me as unhelpful.

iTokio• 5 years ago

Reading the source code is very helpful if you are an experimented programmer that already grasped the basics of the language.

It helps you to see what are the idioms, what does optimized production code look like.

Compare C++ and Go std lib and it’s easy to constate the difference in language goals that they have.

stathibus• 5 years ago

Reading the c++ stdlib source code is never a good idea.

pjmlp15• 5 years ago

Including the workarounds Go has gone through due to lack of generics, e.g. sync.Map.

ralphb4• 5 years ago

In general I would agree, but (as multiple people pointed out) the zig standard library source code is very accessible.

adito• 5 years ago

I beg to disagree with you. I'm newbie and I still found that zig standard library still daunting to read. When people said it's very accessible, I'm curious what people mean by that? What makes it very accessible?

styluss• 5 years ago

It makes less sense when the source code uses idioms that aren't recommended for other code

dnautics10• 5 years ago

It's important to consider that for zig at this stage, "not having valid documentation" is expected. At some point not having valid docs will become considered to be unacceptable.

Forcing people to read the code puts pressure on the code to be clean.

Not writing docs against an unstable API is a strategy to make it freer for the authors to change the API, possibly in sweeping breaking ways (for example allocgate).

the_duke2• 5 years ago

I also tried out Zig a while ago and was frustrated by the lack of good learning materials.

Zig is 6 years old. Rust had much better documentation at this stage of development.

To be fair though: Rust also had corporate backing and a larger fan base contributing to the book and std docs.

Comevius6• 5 years ago

The Zig std source code is easy to navigate, and it won't be documented until it is stabilized.

I prefer to look up the source code either way, examples and the documentation can only get you so far.

rightbyte• 5 years ago

it won't be documented until it is stabilized

Heh ... Good one.

_vvhw14• 5 years ago

"read the source code" comments always strike me as unhelpful.

I can understand why people would recommend reading the source code of projects like Redis or SQLite (and here Zig's std lib) to learn, simply because the code quality is so high.

It's also not like anyone is proposing that there will be no documentation when Zig turns 1.0 (as if high quality documentation and code quality were mutually exclusive!) simply that Zig is not YET at that stage [1].

There's much to love about Zig, and it's always a good time to be reading code, and all the more so while it's growing and shaping because you end up with a deeper knowledge and understanding of what makes a great project great.

[1] Personally, I do find the language documentation to be pretty much excellent and the IRC and Discord helpful—hey, you might even bump into Mitchell Hashimoto also asking questions there. It's the std lib that's a little less, but again, that's in flux and files like `std/mem.zig` are enough of a pleasure to read and learn from. Zig's definitely a swell worth paddling.

hnlmorg• 5 years ago

It also depends on the individual. While I value documentation, I find source so much easy to understand than several paragraphs in English describing how to use language features.

But I know others much prefer reading docs over code.

jlarocco• 5 years ago

This is not a dig at anyone's project or language, but "read the source code" comments always strike me as unhelpful.

I agree, reading the source is a good way to learn more once a person already know the language.

It can be great to help track down a bug, or learn about an obscure corner case in a function, or see more advanced idioms in use, but it's a pretty terrible and unfriendly way to learn a language in the first place.

forrestthewoods5• 5 years ago

Blog author here! I read the source quite a few times.

Almost every language has a dynamic array of some sort. They all do the same thing. They all have slightly different names. push / push_back / add / append. size / length / len / count. If you don't already know the name of a function then finding it is in a sea of text is very difficult and not fun.

Zig ArrayList: https://github.com/ziglang/zig/blob/master/lib/std/array_lis... C++ Vector: https://en.cppreference.com/w/cpp/container/vector Rust Vec: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html

Sometimes I just want to see a list of functions. I can skim a list of 40 functions in seconds. Scrolling 800 lines of code and trying to pick out every single function takes much longer and is much more error prone.

mst11• 5 years ago

When I find myself in such a suboptimal situation, I tend to fall back to

    grep '^ *pub fn' <file>

or equivalent for the language in question.

A smarter approach would probably be a code folding plugin for my editor, but I tend to keep my editing environment deliberately stupid so I can spend my cognitive complexity budget elsewhere.

(this is not to downplay your annoyance, just it seems worth mentioning that stupid problems often have stupid workarounds and I have lots of practice at being stupid ;)

messe6• 5 years ago

I like zig, but agree with many of the points here. A couple of thoughts below,

Zig reference documentation badly needs examples. Can't figure out how to use std.fmt.parseInt.

While yes, Zig documentation badly needs examples, I'm not sure this particular criticism is justified. I would have thought that the usage of parseInt, was fairly obvious from the type-signature:

    parseInt(comptime T: type, buf: []const u8, radix: u8) ParseIntError!T

Or, translated to C++ (and assuming the use of exceptions to return the error):

    template<typename T> T parseInt(const char buf[], uint8_t radix)

> Need to access myArray.items[idx] instead of myArray[idx]. I get it. But very unintuitive and requires knowledge of implementation details.

I'm 50:50 on this one. While it might be nice to hide the implementation here and have a .item(n: usize) member function, ArrayList explicitly manages a contiguous region of memory, so I don't see the problem with exposing it as a slice as part of the interface.

Should I pass the allocator to every function? Doesn't seem great. Maybe I'm supposed to create a global? Globals are evil and feel bad.

As a rule of thumb, libraries should take allocators as arguments to their functions, while applications can either do that or create a global allocator. There is absolutely nothing wrong with using a global allocator in an application; after all it's what almost every other language does. Zig just makes that global explicit.

Globals aren't always evil.

Zig's inability to infer type is annoying. If I create var count and return it and the function return type is usize then var count is obviously a usize.

It's not. It could be any unsigned type of smaller size than usize.

flohofwoe• 5 years ago

It's not. It could be any unsigned type of smaller size than usize.

I think it refers to Rust's ability to "indirectly" infer a type by it's later usage which can be somewhere entirely else in the function (for instance when it's used as return value), while Zig has a more direct type inference (but IMHO Rust's approach definitely isn't "obviously better", because sometimes one needs to read and understand the entire code of a function to get an idea what type a variable might be).

messe6• 5 years ago

I understood that, but my comment could have been more clear. I more meant that it's not necessarily obvious that the type check should infer that it's a `usize` just because the function returns a `usize`. It could be any type that can be implicitly cast to a `usize` which in a 64-bit Zig system is any of `u[1-64]`.

ayende3• 5 years ago

For the record, I find Rust's ability to change the type of the variable _after_ it was declared to be absolutely bonkers for my ability to understand what is going on in the code.

I understand what it is doing, but the fact that changing the return type of a method will change what previous code will compile to is something that I find extremely non obvious and surprising.

Inferring what the type is from the current code, sure. That saves me typing, but from what happens elsewhere looks like time travel.

latch• 5 years ago

ArrayList explicitly manages a contiguous region of memory, so I don't see the problem with exposing it as a slice as part of the interface.

It used to be that you'd get an allocator by taking a pointer to the allocator field (&gpa.allocator), in 0.9.0 that was changed to a function call (gpa.allocator()) and thus broke _a lot_ of things.

Exposing all these fields seems like it'll cause challenges when trying balance backwards compatibility vs breaking changes.

messe6• 5 years ago

In most cases I would agree with you, but I think ArrayList is simple enough that backwards compatibility won't be a major concern. It's literally just a wrapper around slices that handles resizing for you, and there's no real reason for that to change. Exposing the slice underneath is a necessary part of its interface.

hansvm2• 5 years ago

Exposing all these fields seems like it'll cause challenges when trying balance backwards compatibility vs breaking changes.

That's less important than it sounds because the project is pretty explicit about not caring about backward compatibility till 1.0.

zppln• 5 years ago

When I did some Zig a month or so ago, I had great help looking at the tests, e.g.[1].

That being said, the state of the documentation is also the reason why I gave up on it for now. But I'm sure it will improve over time.

[1] https://github.com/ziglang/zig/blob/79628d48a4429818bddef2e8...

anonymoushn5• 5 years ago

I never thought about this until now, but I guess it's actually super weird that ArrayList doesn't expose a getter-by-index and an iterator and instead expects you to use .items.

laserbeam2• 5 years ago

The thing is... Every function in the std works with slices, not woth array lists. You pass slices to mem.tokenize(), you pass alices to mem.cmp(), you pass a slice to sort().

I think that's why ArrayList exposes it for you, so you can just use it as a regular slice everywhere. I, honestly, find that simple and liberating. I'm glad there's no other kind of accessor thing.

Continuous memory is just fast, and if you have some first class support for working with it, it makes no sense to duplicate the api. But again, if you want a hashmap you don't get the slice, for the slice doesn't make sense there...

forrestthewoods5• 5 years ago

I would have thought that the usage of parseInt, was fairly obvious from the type-signature:

Blog author here. In hindsight yes it's obvious.

I think my problem was a lack of understanding of comptime types. They're a little different from C++ / Rust since they're passed as args. Looking back I think I found the Zig docs less "sticky" than other languages. The concepts are familiar but just new enough I don't understand and don't fully remember them.

There's a point while working on AoC that I wasn't sure if Zig had first-class runtime types or not. It has comptime types and it also has a TypeInfo built-in with some degree of reflection? Is that runtime reflection maybe? I think partially? I honestly don't know.

Either way I was confused. :)

laserbeam2• 5 years ago

As far as I know, typeinfo is used at compile time. In general, doing runtime type shenanigans involves implementing things like vtables, and some other weirdness. This breaks "no hidden control flow".

If you do that at comprime instead, the thing that runs at runtime is just memory offsets. You can for example generate code that parses json into 30 types you know at compile time, or you can use things like hashmaps and arraylists and whatnot to do it at runtime.

You get a lot of mileage by just doing the dynamic code away from runtime, and that's one of the benefits of comptime. And it's a slow thing to realize, also not necessarily something everyone cares about.

anonymoushn5• 5 years ago

It has comptime types and it also has a TypeInfo built-in with some degree of reflection? Is that runtime reflection maybe?

I do wish this was explained more prominently! The way this seems to work is that Zig has a lazy runtime for Zig code at compile time that does some interning (such that identical types obtained separately are equal, identical strings obtained separately are equal, etc.), and some types such as type can only exist in this runtime, not in the actual uh "run time" runtime. TypeInfo is for iterating over struct, union, or enum definitions at compile time to generate code. You'd use it if you wanted to write a generic json parser and serializer or if you wanted to write a type that's like an arraylist but internally uses a struct-of-arrays layout. Both of these are in the standard library and make informative reading.

TypeInfo itself is a union that can exist at runtime, but I don't think you can get into a situation where you have something at runtime and you don't know what type it is already. So actually using the TypeInfo at runtime may not be very useful.

Zig appears to not report compiler errors for functions that get optimized out.

This is apparently caused by the laziness. The docs suggest using std.testing.refAllDecls(@This()) to have the compiler check unreachable code. I mean the actual usable docs at https://ziglang.org/documentation/master/#Nested-Container-T... rather than the automatically generated stdlib docs.

ReleaseCandidat11• 5 years ago

No one in the history of the world has ever been confused or upset by a + b calling a function.

That depends on `a`, `b` and the function - I have seen way too many `+` that weren't commutative and/or associative. Languages which do not allow to use _other_ symbols like `⊕` too almost always lead to confusing behavior of 'usual' operators.

And what does `a * b` do for vectors `a` and `b`? Is it the 'usual' 'dot product', is it component wise multiplication (`[.., ai * bi, ..]`) is it 'matrix multiplication' (`a * b^t`), is it the cross product (because the language doesn't allow to define `×` as operator), is it ...

Actually, in C and C++ the implicit conversion and promotion rules are footguns enough.

benttoothpaste• 5 years ago

If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions. What does product(a, b) do?

ReleaseCandidat11• 5 years ago

The rest of the argument can also be apply to functions.

Of course it is, but you can use other functions names than `product`. If the language doesn't let you use any other symbol for the operator but `*`, you're out of luck.

webstrand• 5 years ago

Aside from `NaN`, how is floating point addition non-commutative? It's not associative, but `a+b` will have the same value as `b+a`.

smoyer• 5 years ago

It's interesting that the author goes through AdventOfCode hell (the code challenges are supposed to be hard, not fighting with your language), critiques Zig's raison d'etre and then predicts a bright future.

To me, this seems like one of those projects that starts its marketing hype too early, gets a negative reputation and then never recovers even if the original promises have been fulfilled.

formerly_proven• 5 years ago

That seems like an unfair criticism of Zig to me. The project is very clear that the language isn't stable, the compiler has bugs, the generated docs being no good and releases not being backwards compatible. The community is onboard with that. If you're doing something with Zig, you're not going to complain that for example 0.9.0 required a find'n'replace to fix every occurrence of Allocator or changed the layout of std.os.

eterm• 5 years ago

[Compiling] takes about ~3 seconds minimum which is frustratingly slow

I feel old, I know that any time is an opportunity to get distracted but 3 seconds doesn't strike me as a long compile time.

Or is that a typo for 30, which would make more sense, which is definitely long enough to be a frustration?

delphLonepaw7• 5 years ago

Depends on the machine, on large projects, zig can take up to 10-15 seconds in my i5 12gb, ofc, after the first hit it becomes 0.01 recompiling without change (in case you removed the out and not the cache) and the first time you compile it takes a bit (not counted) since it will precompile std (or that is what I've seen) in a global cache (just so std does not make your code take longer to compile), small things takes 1-3 seconds depending on how comptime heavy I make my code do.

Zig comptime is the part that takes a bit more time compiling for being an interpreted version of the language, and the more comptime you use, the more time it takes (for a bit, even comptime heavy code can gain just a few seconds out of it, of course can gain 30 minutes, but you would be making like, weird jumps and generating strings on comptime that gets used on runtime, or an expensive algorithm that will take a long time to execute)

ralphb4• 5 years ago

That's funny. I am old, and I think 3 seconds is unacceptable.

I use zig anyway.

llimllib3• 5 years ago

That complaint was weird, here's my day 7 solution in zig built in release mode:

    $ time zig build-exe ./a.zig -O ReleaseSmall

    real 0m1.728s
    user 0m1.544s
    sys 0m0.292s

Which is actually slower than running the entire solution in debug mode:

    $ time zig run a.zig -- input.txt
    min 337 342641
    min 470 93006301

    real 0m1.138s
    user 0m0.789s
    sys 0m0.270s

Totally possible that it's much slower on the dev's machine, but if he's a VR developer it seems weird that he'd have a low-powered box.

[1] https://github.com/llimllib/personal_code/blob/master/misc/a...

forrestthewoods5• 5 years ago

Blog author here. I'm an Intel i7-8700k desktop. A few years old at this point, but quite beefy.

Maybe this is a Windows issue? If I run "zig build" and then immediately run "zig build" again it still takes 3 seconds.

Accacin• 5 years ago

I read it differently to you. I don't think he meant three seconds is long for compiling in general, but when you are unfamiliar with the code and trying to make it work, having to wait three seconds everytime you make a small change adds up to become annoying.

I think that's why he would like a `zig check` command that would give him these errors and warnings faster.

gameswithgo• 5 years ago

when you don’t have in editor compiler errors and are trying to learn instant feedback can be nice

delphLonepaw7• 5 years ago

fun stuff, zig syntax error stuff is handled both by zls and zig fmt --ast-check

(or if you care only for one file) zig ast-check =)

For compile errors I think zig build is the only way

AnIdiotOnTheNet3• 5 years ago

Honestly I'm surprised it takes 3 whole seconds. Unless I'm importing zigwin32 I don't think I've ever had a Zig project take that long to build. But then again, I avoid linking to C at pretty much any cost, maybe OP didn't.

stephc_int133• 5 years ago

I disagree from this part:

"I also think it's partially wrong. No one in the history of the world has ever been confused or upset by a + b calling a function."

It depends. If this is simple math on vectors I think it can be OK but it should probably be a built-in feature of the language as this is common, solved and we all implement it the same way (for short vectors at least)

But the + operator has been abused in the past, especially with strings concatenation and I think this is a huge liability. Such an innocent looking operator, the simplest of all operations, leading to a function call, a memory allocation and thus a very real potential memory leak, all of that hidden from the eyes...

In my opinion, clarity should have priority over anything else. If an operation is computationally complex (especially with side effects) it should be at least hinted to the reader by a function call.

tialaramex12• 5 years ago

I also would prefer not to have + as concatenate, and Linus feels strongly enough about it (and has enough influence) that Rust for the Linux kernel does not have Add and AddAssign overloaded on string types, among many concessions.

However I think in general purpose programming we lost that battle when Java special-cased the operator. There's no overloading in Java, you can't have + do the Right Thing™ in Java for your 3D vector class, but it does concatenate strings because people had begun to expect that.

Also, while I'm in this topic, the author argues they don't want anybody overloading either of the member access operators (which is something Python kinda-sorta supports) but notice that Rust effectively does this all the time and nobody freaks out because it feels completely natural.

Your Box<Thing> isn't a Thing, so, why can you call Thing methods on it? Because it is transparently passing those into the underlying Thing by implementing the relevant overload features from core::ops and all of Rust's smart pointers work the same way.

misfortunate::Double shows that this gives very strange behaviour if somebody uses it inappropriately, a Double<Thing> is actually two Things inside, but when you change it, you're changing one of them, while any immutable references are to the other one... an eerie experience.

oldsecondhand• 5 years ago

However I think in general purpose programming we lost that battle when Java special-cased the operator.

It was already special-cased by Pascal.

pjmlp15• 5 years ago

Why Java given the history of programming languages between 1950 and 1996?

oconnor663• 5 years ago

Such an innocent looking operator, the simplest of all operations, leading to a function call, a memory allocation and thus a very real potential memory leak

I hadn't considered the memory leak angle of this, and now that you mention it it's clearly a driving concern here. When freeing is explicit, it's a problem to heap-allocate temporaries. (And I guess the addition operator would also require a third operand to supply the allocator?)

I'm still a big fan of destructors, and how they make this problem mostly vanish. But I understand that it's hard to make them efficient without move semantics, and maybe also a global allocator so every object doesn't need to store an allocator pointer? What other interactions am I missing?

stephc_int133• 5 years ago

Strings are complex entities, I am not sure if there is a perfect way to handle them.

In my case (I use my own framework) I use a lot of makeStringWith* functions that all allocate in the same global scratch buffer (one per thread) and I don't care at all about releasing the memory.

There is simply one function to clear reset all scratch buffers, it has to be called explicitely by the user, most of the time once per frame (I create video games) but it can also be when the current job is done or never.

From my perspective it is very efficient and reliable, never had to solve a bug related to this mechanism.

juped• 5 years ago

At the very least, it's wrong that no one has ever been upset by this; many people have been very vocally upset by this.

otabdeveloper42• 5 years ago

Such an innocent looking operator, the simplest of all operations, leading to a function call, a memory allocation and thus a very real potential memory leak, all of that hidden from the eyes...

It's not a given that floating-point addition is a simpler operation than string concatenation.

If you're serious about what you write, then all operators should be banned.

nmilo2• 5 years ago

What is a case where floating-point addition is more complicated than a string concatenation? Are you referring to some obscure architecture?

mst11• 5 years ago

The DSL I'm currently hacking around on has ++ for string (and list) concatenation and using a -seperate- operator seems to rather help.

(I've yet to conclude if stealing ++ for this rather than preinc/postinc was a terrible mistake, so far in context it hasn't seemed to be but I'm still keeping an eye on the question)

brandmeyer2• 5 years ago

Perl uses ~ for string concatenation.

Nothing says that you cannot use both infix "++" for concatenation and unary ++ for increment. "-" is both a unary prefix and binary infix operator, for example.

rslabbert• 5 years ago

Interestingly since you can't pass an allocator to an operator call, there is some extra guarantee around whether a hypothetical overloaded operator can allocate. If you implement it for a vector type which doesn't contain an allocator reference, then you're sure that any operators won't allocate.

kristoff_it4• 5 years ago

Hi, I'm Loris from the ZSF.

I think this is a fair post overall given what it is: a log of what it was like for one specific person to use Zig for AoC for the first time.

I'll spend some words on some of the things mentioned and then add some more useful advice for forrestthewoods at the end.

From my perspective the complaints mostly were about now knowing things which had varying degrees of discoverability.

The first point in Day 1 about mixing optionals and error unions is an example of something very easy to discover (by reading the language reference), so I personally would consider it an unlucky mistake by the author.

The second point (how to print an integer) is about something way less easily discoverable than in the previous example. You need to learn about how to print, then about `fmt` and from there the only authoritative place that contains information about format specifiers is the doc comment of `std.fmt.format`.

This second example is the kind of thing that we're the weakest at communicating to people because it's not a feature of the language itself (so it doesn't belong to the language reference) and, while you could in theory find this stuff in the stdlib autogenerated docs, you still have the problem of having to discover first what to search for. This is especially problematic when Zig breaks away from what's common in programming languages. One example of that is the fact that Zig has no print statement.

I've given some talks and written some articles about how to do common things and find stuff in the standard library:

https://www.youtube.com/c/ZigSHOWTIME

https://zig.news

and, as the author metioned, Zig Learn is by far the closest thing we have to a "Zig book".

https://ziglearn.org

The problem with creating content for the standard library is that it keeps changing and it's not yet the focus of development. As the language matures more content is being created (just look at how many explainers are being posted to zig.news alone) but we're not yet in a position to invest into something like a book.

The author also mentioned issues with the autogenerated docs for the standard library. Those docs are currently incomplete and in fact greet you with this message as soon as you open them:

    These docs are experimental. Progress depends on the self-hosted compiler, consider reading the stdlib source in the meantime.

I've seen some comments here about how recommending to read the source code is unhelpful. I vehemently disagree because of practicality first (if something is not documented elsewhere, then that's the best you can do) and second because reading the source code should not be considered something primitive that developers used to do before discovering fire.

We all should read more and write less.

That said, Andrew is going to help me start this week the work on a new doc autogeneration system based on a different design that the current (incomplete) one. I'll do most of the work while streaming on Twitch so if anybody has opinions, complaints or questions, you know where to find me: https://twitch.tv/kristoff_it

Going back to the post, there were also some impressions that we all fully agree with (and are working on improving), a good example being

Bit-shifting is a monumental pain in the ass.

Yes, it indeed is. See: https://github.com/ziglang/zig/issues/7605

Ok, so, here's my advice to forrestthewoods if you're ever going to try Zig again:

[1] Interact more with the community if you want to be pointed quickly in the right direction. You mentioned the discord server so you already interacted with people. Leverage them more: ask questions in #zig-help and don't be afraid to ask why things are a certain way. You'll probably be way less annoyed by, say, ArrayList requiring you to access its `items` field to iterate, if somebody explains to you that ArrayList is a normal userland struct defined in the stdlib and that in Zig there are no "magic methods" that the compiler picks up to do iteration etc. Or maybe you won't be less annoyed, but at least you will know if something is intentional or if it's just something that we haven't gotten around fixing yet.

[2] Try to learn Zig doing something else other than Advent of Code. AoC doesn't really let Zig show it's potential because it doesn't ask you to do good software engineering. You're just supposed to write a script that gets you to the correct answer. Try instead doing a small project where you have to validate input, produce useful error messages to the user, clean up resources properly (sockets, memory, ...), etc. You will find that Zig will be much better in this second case. I'm saying this based on first hand experience btw, I've streamed the first 16 days of AoC from this year, you can find the recordings in this playlist: https://www.youtube.com/watch?v=wo580tbLSR8&list=PL5AY2Vv6Es...

I stopped after day 16 because I felt it the exercises didn't really help me showcase any big strength of Zig, so I started working on other stuff instead.

dnautics10• 5 years ago

The second point (how to print an integer) is about something way less easily discoverable than in the previous example. You need to learn about how to print, then about `fmt` and from there the only authoritative place that contains information about format specifiers is the doc comment of `std.fmt.format`.

I don't know if ZSF can guide this or if we can incept it into Andy's head, but if there were any coordinated plan to "solidify certain parts of the stdlib sooner than other parts" the std.fmt.format would be high on my list. And document it. Hell. document it, even if it changes around all the time. I'm often forgetting how that beautiful bastard works and having to jump to the comment in the stdlib is kind of annoying.

AndyKelley• 5 years ago

Unfortunately I want to destroy it with fire. I am not happy with formatted printing at the moment. But that's something that will ruin a lot of people's day so it will have to be done carefully.

To be less dramatic: I do intend to wildly break formatted printing at some point.

Point taken though. Perhaps it deserves its own seat in the roadmap.

megumax• 5 years ago

My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much. Zig still can't proper handle UTF-8 strings [1] in 2022, which is kind of unfortunate, because it's a `requirement`. In a `recent` interview[2], he claims that Zig is faster than C and Rust, but he refers to extremely short benchmarking that has almost no value in the real world.

At least Rust, as blamed and loved as it is, delivered a stable compiler and people started working on the ecosystem (in the first years, most packages were working only on nightly, but at least there were crates available). The ecosystem for zig is insignificant now and a stable release would help the language.

[1] https://github.com/ziglang/zig/issues/234 [2] https://about.sourcegraph.com/podcast/andrew-kelley/

ralphb4• 5 years ago

Rust was started in 2006. [1]

Zig was started in 2015. [2]

[1] https://en.wikipedia.org/wiki/Rust_(programming_language) [2] https://en.wikipedia.org/wiki/Zig_(programming_language)

octoberfranklin7• 5 years ago

The language called "Rust" prior to 2013 is a completely different language from what people today know as "Rust". That language had a garbage collector, mutable aliasing, and no borrow checker (the three most unique features of today's Rust), and was basically "golang with different syntax":

http://smallcultfollowing.com/babysteps/blog/2012/11/18/imag...

The whole language got rebooted shortly after the blog post above, mostly because the borrow checker made so many other things suddenly unnecessary or trivial. What we call Rust today is at most 9 years old, and any similarities to pre-2013 Rust are strictly superficial syntax. They share a name and some syntax, sort of like Java and Javascript do.

Zig today at T+7 is not where Rust was in 2020 at T+7.

delphLonepaw7• 5 years ago

I don't think a lot, I have no problems with UTF-8 strings (unless you speak in the source code, haven't tried), faster than c and rust when it can, ofc, I saw a rust program, made my own with zig, and it's fast , and I didn't even optimize that much.

Compiling is faster than rust and C a lot of the times

We have packages, and a good few, thing is, this is no rust big, we don't have mozilla nor to backup and work into it.

I don't think is overpromise, Vlang is overpromise, zig atm, is slowly getting there, no promises on when

kristoff_it4• 5 years ago

My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much.

Have you, like, seen the release notes for 0.9.0?

https://ziglang.org/download/0.9.0/release-notes.html

Zig still can't proper handle UTF-8 strings [1] in 2022

There's plenty of discussion on the subject in basically every HN thread about Zig: the stdlib has some utf8 and wtf validation code, ziglyph implements the full unicode spec.

https://github.com/jecolon/ziglyph

You might not like how it's done, but its factually incorrect to state that Zig can't handle unicode.

In a `recent` interview[2], he claims that Zig is faster than C and Rust, but he refers to extremely short benchmarking that has almost no value in the real world.

From my reddit reply to this same topic:

This podcast interview might not be the best showcase of the practical implications of Zig's take on safety and performance. If you want something with more meat, I highly recommend Andrew's recent talk from Handmade Seattle, where he shows the work being done on the Zig self-hosted compiler.

https://media.handmade-seattle.com/practical-data-oriented-d...

Lots of bit fiddling that can't be fully proven safe statically, but then you get a compiler capable of compiling Zig code stupidly fast, and that's even without factoring in incremental compilation with in-place binary patching, with which we're aiming for sub-millisecond rebuilds of arbitrarily large projects.

The ecosystem for zig is insignificant now and a stable release would help the language.

I hope you don't mind if we don't take this advice, given the overall tone of your post.

iainmerrick• 5 years ago

you get a compiler capable of compiling Zig code stupidly fast, and that's even without factoring in incremental compilation with in-place binary patching, with which we're aiming for sub-millisecond rebuilds of arbitrarily large projects

That sounds great! But at the same time people in other threads here are talking about 1-3 second compilation times for Advent of Code solutions (which I presume are smallish). Can you summarise where that really fast compiler comes from, to save me searching through that talk video? Is this something that everyday users will be able to use in typical workflows?

Kwpolska2• 5 years ago

Why does something as basic as uppercasing a string or decoding latin1 require a third-party library? I would expect that to be part of stdlib in any language. Also, why does that third-party library come with its own string implementation? What if my dependency X uses zigstr but dependency Y prefers zig-string <https://github.com/JakubSzark/zig-string>? Basically all languages designed in the past 30 years have at least basic and correct-for-BMP Unicode support built-in/as part of stdlib. Why doesn’t Zig?

jibalt20• 5 years ago

My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much.

My biggest problem with your comment is that it is completely and utterly false.

At least Rust, as blamed and loved as it is, delivered a stable compiler

After MANY years and numerous complete redesigns.

jmull• 5 years ago

I also did AOC 2021 to learn zig. But I found zig interesting and useful.

As someone with only 18 days more experience than OP it’s a little silly for me to say, but I think OP is getting put off the the normal learning curve of a new language and standard library. The struggle to learn different patterns faded away after not too many more days. Zig is pretty simple, and while the standard library is barely documented, it is pretty well organized and straightforward to understand.

I’m pretty interested to see where zig goes, and I’m hopeful about it.

(As mentioned, zig is a work-in-progress. The final form might be significantly different that what is there now,)

jhack• 5 years ago

I don't know how a language that sets itself up to be a better C turns into this monster of horrible syntax and patterns that's nothing like C at all.

pphysch• 5 years ago

Hey, it's unreleased so we can project our personal vision of "ideal C" onto it.

Then when those design choices get hardened into a 1.0 it will become just-another-language and we will inevitably feel let down and move into the next attempt at a Perfect Programming Language. So it goes.

githubholobeat• 5 years ago

I completed 10 days of Advent Of Code 2021 in Zig and loved the learning experience. Then I rewrote a snake game I made originally in Elm into Zig and compiled it to WASM. So now it runs in a browser. There is Zig standard library documentation on Zig website, but if you want to see the missing parts, go to GitHub and browse stdlib source files. Each source file contains test cases that are sufficient for understanding how it works.

ogogmad• 5 years ago

Would there by any interest in an imperative language with a basic Standard ML type system?

Personally, while I find the imperative paradigm more intuitive than the functional paradigm, I believe functional type systems are simpler and more "right" than imperative ones are (which have been taken over by OOP). There are multi-paradigm languages, but these have large numbers of features, and complicated type systems, and I want something simple. Is there interest in this? Thanks.

By SML type system, I'm thinking:

  - Algebraic data types
  - Anonymous functions
  - Pattern matching
  - Simple generics
  - Type inference
  - Simple modules and implementation hiding

combined with some approach to operator overloading (which SML doesn't consider at all). And to remind you, the paradigm should be imperative, not functional.

I'm thinking a use case might be in numerical linear algebra, but with support for multiple different scalar types including floats, ints, complex floats, dual numbers (for autodiff), "codual numbers" (for better autodiff), bignums, quaternions, symbolic algebra, etc. The functional paradigm is not suitable here, but Julia is perhaps overcomplicated.

quells• 5 years ago

I think you just described Rust (although you have to deal with / get to take advantage of the borrow checker).

shwestrick• 5 years ago

OCaml is pretty close already to what you're describing. The OCaml ecosystem fully embraces imperative programming. And if the syntax of OCaml is problematic, then perhaps ReasonML (https://reasonml.github.io/) is what you're looking for: a curly-braces syntax for OCaml.

jolux7• 5 years ago

OCaml and Rust both offer these, OCaml does overloading mostly with module functors and Rust with traits. Of course they’re both multi-paradigm, OCaml is also really good for functional programming.

Shadonototra• 5 years ago

I don't think it is that hard to learn

I'm not a professional programmer, this is all a hobby for me and i managed to pick and write an entire game with it

maybe you are just bad as a programmer (nothing wrong with that)

you have to learn how to learn, not everybody can do that (and it's fine)

that being said, zig is a language in the making, some areas are rough, but that's to be expected

templix2• 5 years ago

maybe you are just bad as a programmer (nothing wrong with that)

This was actually my impression after reading the post. A bad programmer making a lot of ill-informed complaints. Zig is an unfinished low-level language. Not suitable for bad programmers.

wink• 5 years ago

This is a pretty bullshit argument. People can have a really easy or hard time learning a language, depending on said language. It can be too far from what you know, or too similar but just different enough.

Also it's a log of personal experience and not titled "an objective criticism of Zig". I've been interested in Zig a little for a while and this was awesome to read. It hasn't made my interest any smaller or bigger, it's simply a description of one beginner's journey, and if the Zig people are smart they will analyze it and then decide which points are valid and which ones can be ignored. Neither ignoring everything nor accepting everything would probably be useful.

socialdemocrat• 5 years ago

Zig is a very low level language. I think the fancy type system can trip up people into thinking they are working with a high-level language.

Zig is basically C with a fancy type system, so you should not expect things like special String types, overloading of index based access etc.

I think the author was thinking that Zig was very close to Rust or C++, when in reality it is much closer to C. I had to keep reminding myself of that many times as I was learning Zig.

I had my own struggled with Zig, but not quite as much as the author. I think will probably have a much better experience if you don't try to jump and code right away but read some articles or listen to some videos to get a sense of the overall philosophy of Zig.

I am normally against having to look at source code, but with Zig that is kind of needed but also not quite as bad as it sounds. Zig code base is not that large and it is relatively easy to search. You can lookup a Zig function signature very easily. You need to do this if you are going to use any of the standard library apart from the most basic stuff.

k__3• 5 years ago

Interesting.

I had the impression Zig proponents were praising it because it wasn't as low-level as Rust.

klyrs• 5 years ago

Quite the opposite. The very broad-brush overview is that zig aims to replace C and rust aims to replace C++... but among other issues with that analogy, that can't happen unless zig and rust have a dead-simple integration story.

nix23• 5 years ago

>Feature Highlights Small, simple language
>There is no hidden control flow, no hidden memory allocations, no preprocessor, and no macros.

https://ziglang.org/learn/overview/

It try's (achieves?) to be a C without the flaws and historic ballast.

jibalt20• 5 years ago

Where did you get that impression? No one has ever done that.

yjftsjthsd-h• 5 years ago

Zig is basically C with a fancy type system, so you should not expect things like special String types,

If I can't have nice strings, what should I be expecting from a fancy type system?

dundarious4• 5 years ago

Zig's "fancy" (I don't think they're that fancy) type features that IMO make it a great C alternative are:

- non-null pointers, and distinct types for single-item pointers and multi-item pointers (multi-item pointers are rarely used except indirectly via slices, so unchecked pointer arithmetic errors are largely banished)

- builtin tagged unions (AKA algebraic data types) with very pleasant to use switch logic -- it can't be overstated how nice the "handle all the cases" logic is in Zig in general (catch, orelse, if-else/switch expressions)

- a decent proposition for errors (the error union, and try keyword), but I haven't decided if I really like it yet

There's lots of non-type stuff there too. I was writing personal projects in C without libc, but found there to be a lot of annoying work involved -- happy to do it, but it's not earned/fruitful annoyance, more like a long list of incidental historical annoyances. Zig seems to cater to the same level of the stack, but with all that boring stuff taken care of.

octoberfranklin7• 5 years ago

I still can't figure out how Zig proposes to prevent undefined behavior without a borrow checker (aka MLKit regions) or GC.

AFAICT the answer is "inject as many runtime checks as needed" although the docs seem to go way out of their way to avoid making this explicit.... or deal with the fact that these checks are now runtime failures rather than compile-time failures, and therefore need code to handle them.

It seems like it would be the same as writing Rust code using std::cell instead of references, except that Rust would force you to insert handlers for all the new failure modes this would create (of course you could just panic!(), but at least the compiler would force you to insert those panics...).

_vvhw14• 5 years ago

You're conflating undefined behavior with spatial/temporal memory safety, the latter of which is what is 100% prevented by Rust's borrow checker, provided you're not interfacing with hardware, in which case I believe that things change more in binary fashion.

However, Zig treats memory safety not as an extreme-at-all-costs but as a spectrum (there are reasons for wanting to think like this, at least when writing low-level code if you want to make more use of the hardware), getting 100% on the spatial memory safety front and reaching to 50-75% on the temporal memory safety front through the GPA. That's already an order of magnitude more safety than C, at which point memory exploits have dropped in ranking, and you should be more concerned about things like explicit control flow, error handling and checked arithmetic, not to mention the orthogonality of the language.

Furthermore, in the systems world, there are many safety critical systems where dynamic allocation and multi-threaded control planes are simply off the table to begin with because they're dangerous in some domains and not as safe as static allocation and single-threaded control planes, which are less dimensional and easier to reason about. And in those cases, UAFs and multi-threaded races are less of a concern (still a concern, but less).

Also, Rust won't protect you from all undefined behavior, and Zig often helps more than you think. For example, you might be surprised to hear that Rust has checked arithmetic off by default in safe builds, whereas Zig has this enabled. I've done a little security work on some large systems and the decision to disable checked arithmetic always blows my mind. Integer overflow and underflow are right up there as threat vectors when writing anything that's touching hostile data.

I'm waiting for the day when Rust changes direction on this, and I think there's a chance this will happen because the alternative status quo of not checking arithmetic (at all) is just not tenable, at least not if we care about safety and security holistically, and not only memory safety.

jibalt20• 5 years ago

Zig doesn't propose to prevent UB (in fact the docs say that it takes aggressive advantage of it for optimization).

(Neither does Rust.)

pyrale• 5 years ago

The opinion that reimplementing AoC in two languages was not a good idea resonates a lot with my experience.

Every year, I see people quitting their AoC run with frustration, because they don't measure their effort and try to complete each puzzle daily. The usual scenario is that, at some point, they block on a problem and spend longer than they should, or they can't solve the problem because they have some other thing to do. The next day, they try to solve that puzzle and another one, and as work piles up, they start doing it joylessly to catch up. After a while, it doesn't work anymore, because people are stressed, because they code poorly just to finish rather than taking pleasure in their craft. The strict calendar can become deadlines that remind of work woes.

For a person not used to sport code, AoC can take an hour to solve, sometimes more. Over the whole advent, people can easily work for 30 to 40 hours more than they are used to. In terms of work hygiene, this is not good. Not everyone has a week's worth of work to use just before the end of year.

I would advise people doing AoC to time their effort, and not hesitate to stop a puzzle and write it down for later in the year.

kello• 5 years ago

I definitely fall into this category. I stopped on Day 8 Part 2 this year getting frustrated and falling behind. Good practice for sure and I feel more prepared for next year, still, just wanted to post that I identify myself in what you mention here!

Ostrogodsky• 5 years ago

If there is something I have learned over the years and I have confirmed on this thread is that if you dont like a language or the direction is taking the best course of action is to pick another one. Trying to argue with the developers is a unproductive use of your time. Another option is to wait 3-5 years and revisit the project, you will be surprised that in 90% of the cases either the project is dead on the water or the same problems still remain.

defen3• 5 years ago

The author is not excited about "No hidden control flow", but as a code reader it's really nice. It means that the only context you need in order to understand the control flow of a given line of code is that line itself. You don't need to check for overloaded operators, exceptions, virtual functions, etc. It's this property of Zig that I think makes "read the stdlib source" actually a viable strategy for learning how to use it.

cbdumas3• 5 years ago

What did you think of the example in the article about vector math? Seems like that's an area where operator overloading actually makes the code more readable. Maybe it depends on the problem domain you're working in.

defen3• 5 years ago

I agree that with vector math, overloaded arithmetic operators are easier to read. However, I don't see how you could add "overloading, but only for actual math" - once it's in, people will repurpose it for all kinds of cursed purposes.

The implementation would probably be ugly, but I wonder if it could be implemented by using a comptime string to represent the operation, e.g. something like:

    fn doMath(comptime op: []const u8, args: anytype) MathReturnType(op, args) {
        // TODO: implement me
    }

    const result = doMath(
        \\a + b
        ,
        .{ .a = a, .b = b }
    );

Where the implementation would call `.add` etc on the parameters when infix operators were used.

meheleventyone3• 5 years ago

It’s a bit of a non-issue really. Once you’ve worked with the non-overloaded version for a while you quickly get used to it. The overloaded version is also superficially simple but loses information. For example, multiply versus multiplyScalar versus applyQuaternion on a vector which might all be represented by overloads of the multiply operator.

hansvm2• 5 years ago

Zig is fairly low-level. GPU compute kernels are already defined as stringly typed things that get thrown into an additional non-Zig compilation step; I don't know that I'd feel too badly about somebody having to write a tensor DSL that Zig could interpret at compile time.

Do you have any examples of situations where people would be writing a lot of code with custom operators where each individual block is pretty small and having to deal with a DSL of some flavor would be especially burdensome?

meibo• 5 years ago

Anyone though that advent of code was unusually hard this year, especially at the start? Nothing unsolvable, but I usually do these with my SO and they got stuck on the second day, wherein we usually get to day 10 or so. Felt like it picked up way sooner.

dagmx2• 5 years ago

I think it depends on what problem spaces you're in regularly. Some people on the Reddit found it much easier than previous years, others found it much harder.

It was often around the difficulty of the exponential problems, but most were okay if you're very familiar with grid data, hierarchy traversal and caching.

jolux7• 5 years ago

To me the biggest difference between Rust and Zig in practical terms is that Zig does not offer statically safe resource management like Rust does, and as far as I know they have no intentions of doing so in the future because they think it’s less important than all this stuff about control flow. There are a lot of interesting ideas in the language but my disagreement with them on this issue is so fundamental that I don’t feel compelled to investigate it further.

Nonetheless I had gotten the impression from many posts on here before that Zig was a lot closer to finished than it really is, it seems like they’re not quite half way to something as polished as Rust 1.0. It is probably unfair to judge the language against Rust in its current state. Hopefully in a few years they will have figured out the memory safety problems and the stdlib documentation will stabilize more.

aidenn0• 5 years ago

Yeah, I've tried out zig and it's about at the point where Rust was when there were like 5 different pointer sigils and a GC was still included.

nyberg2• 5 years ago

It's an open question [1] along with other safety checks both comptime and runtime [2]. The issue here is a balance of keeping language complexity low while providing safety at the same time and not depriving users of control when they know better than the type checker/lifetime analysis.

[1] https://github.com/ziglang/zig/issues/782

[2] https://github.com/ziglang/zig/issues/2301

jolux7• 5 years ago

not depriving users of control when they know better than the type checker/lifetime analysis.

You're never deprived of control though, that's what unsafe is for, and it provides roughly the same level of safety as C or Zig would.

octoberfranklin7• 5 years ago

This is such a squishy value proposition, which is why people aren't taking Zig seriously.

Rust's value proposition is simple: no GC and no undefined behavior. Period. Nothing else has that.

Comevius6• 5 years ago

There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away memory management. You can do whatever in Zig, write a specialized allocator that's verified to be correct, even for a microcontroller with 2 KiB memory. Zig is a machine-oriented language, which means no hidden control flow, no hidden allocation. You can write a garbage collector or a compiler like Rust has too if that's what you need.

pjmlp15• 5 years ago

Thing is, if Zig is C, why bother at all, we already have C for it.

jolux7• 5 years ago

memory-safety can be achieved in other ways

I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract.

Zig is C, it's not meant to abstract away memory management.

This is just hiding the ball though. Why don't we want abstractions on memory management? There is no runtime cost to providing the abstraction that Rust does. As such, "machine-oriented" is an ambiguous description of the difference here. The whole lesson of Rust is that there's nothing fundamental about the abstractions the machine itself provides, and we can create better abstractions without losing our orientation to those concerns.

octoberfranklin7• 5 years ago

nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways.

Not other ways. One other way. Just one. Garbage collection.

pjmlp15• 5 years ago

In terms of safety in systems programming, Zig is hardly better than something like Modula-2 or Object Pascal.

It just happens to have a better syntax for the C crowd.

ryukoposting3• 5 years ago

I feel like Nim is a much closer comparison than Rust. All three could be described as "grassroots projects on a holy mission to replace C and/or C++," but Nim and Zig are more similar in terms of operating budget/team size/adoption rate.

I may be a bit biased, but many of the problems mentioned in the post are the sorts of things I haven't dealt with in Nim for probably 2 years. Nim's error messages are still hit-or-miss and {.gcsafe.} still haunts me in my dreams, but the stdlib and language documents are great, and most of the annoying gotchas have been fixed.

octoberfranklin7• 5 years ago

Rust isn't on a holy mission; it's simply the only memory-safe language without a garbage collector.

It's really that simple. There is no international conspiracy behind Rust's popularity. It's the only thing that can do what it does in that respect.

_vvhw14• 5 years ago

I think the comparison should be more nuanced and holistic than only memory safety, if it is to be a discussion on security and not theater.

For example, to get the conversation started, how do both languages compare in terms of checked integer arithmetic? Do they enable checked arithmetic by default in safe builds with an opt-out for performance, or do they leave default builds unsafe with an opt-in for safety?

Another example, JavaScript is 100% memory safe, does it follow that we can expect to see less exploits against NPM than C? Both ecosystems are massive, but I'd wager that most product release security teams are more stressed out about NPM than C dependencies right now. Not to say that they shouldn't be running C dependencies in sandboxes or be evaluating the risk of C (and remember that Zig is an order of magnitude safer than C, much closer to Rust actually, and more so in some areas). But NPM is probably getting more attention. Same thing for bug bounty issues reported. Probably more for NPM supply chain vulnerabilities than anything else. All 100% memory safety, and yet security is still a thing.

It's the many small decisions like these, along with thinking of security not as a binary extreme but as a probabilistic spectrum, that are more interesting to me.

jolux7• 5 years ago

All 100% memory safety, and yet security is still a thing.

And nobody has ever claimed that memory safety is the only thing that matters with security, but it’s definitely high on the list. Can you imagine how much more of a nightmare NPM would be if JavaScript weren’t memory safe? This is the relevant counterfactual.

Zig is an order of magnitude safer than C, much closer to Rust actually, and more so in some areas

Hard disagree. It’s definitely safer than C, (in terms of UB) but you can tell it’s not even close to Rust on a number of axes (yet?): https://scattered-thoughts.net/writing/how-safe-is-zig/

As for integer overflows, I don’t think they are nearly as big a security concern in a memory safe language with bounds checking. Feel free to correct me though.

travisgriggs• 5 years ago

Some mild office competition didn't help.

Does that mean that someone at his office had better luck and should be writing the success article? Or something else?

ryukoposting3• 5 years ago

Zig sounds like it's kind of in the spot Nim is in- many great ideas, most of them executed well, but a bunch of unresolved quirks that take away from the experience.

templix2• 5 years ago

Seems like the author isn't used to low-level programming languages. Zig is a great C replacement.

ncmncm11• 5 years ago

When I saw

I try to keep my C++ simple and somewhat C-like.

... I knew this would not be very informative.

On one hand, the author's failure to take advantage of the power C++ offers means he will likely also fail to see how to use well what Zig does offer. (One doubts he makes any more effective use of Rust, another powerful language, than of C++.) At the same time, it should make him a better prospect to become a Zig user, not missing powerful features that could make him a more productive programmer.

But he is right that "no hidden control flow" is an anti-feature. What they call "hidden control flow" seems to be what we know of as destructors (or, in Rust, the Drop trait) that is about the only piece of programming automation invented in 40 years.

One might as well dispense with running water and cooked food.

_vvhw14• 5 years ago

But he is right that "no hidden control flow" is an anti-feature.

Hmmm, "no hidden control flow" is at least what I want writing distributed systems, storage engines or device drivers.

Calling it an "anti-feature" is dismissing important domains for system languages where control flow in the control plane needs to be explicitly visible, and where the necessity for things like static allocation and NASA's "The Power of 10: Rules for Developing Safety-Critical Code" mean that destructors during the lifetime of a system are an anti-pattern anyway.

ncmncm11• 5 years ago

Destructors are a powerful tool to ensure that required events occur, an important part of safety-critical coding.

Static allocation is a valuable method that is wholly compatible with use of destructors. If you imagine that freeing dynamically-allocated memory is the main use for destructors, you have utterly failed to understand them.

jibalt20• 5 years ago

There's a Hello World program at the beginning of the Zig Reference Manual. It of course shows how to print things. Many other of these failures could be avoided by reading that document, reading Zig source code in the distribution, looking at issues on Github, reading blogs and watching presentations by Andrew Kelley, etc.

Zig is far from a finished project so it's premature to complain about most of the things you are complaining about.

losvedir• 5 years ago

Building is slow. It takes about ~3 seconds minimum which is frustratingly slow when I'm fighting basic syntax errors. I wish there was a fast zig check.
Lack of zig-analyzer makes learning hard.
zig fmt src/main.zig is nice. Wish it automatically ran on all files.

I also did (well, "am doing", can only work a bit each day and am plugging through day 7 right now) AdventOfCode in Zig this year.

These points here didn't resonate with me at all. I wonder if the author knew about or tried ZLS[0]. I had it on and integrated with my VSCode and it would check a lot of things as I went and format on save. I think I followed something like this[1] to set it up.

[0] https://github.com/zigtools/zls [1] https://zig.news/jarredsumner/setting-up-visual-studio-code-...

nikolay• 5 years ago

I did improve my Go skills solving all problems in Go, learning many things the hard way, but at end my solutions were way longer and so much less ergonomic than the NumPy & Python-based I saw by the top 100 guys! I mean, come on, Go doesn't even have built-in min(), max(), abs(), and other basics (for ints)! Some of the top developers had their solutions done in a shorter time that I needed to read the overly convoluted and confusing problems. I just didn't appreciate the infantile, and wasteful pseudo-comical style of problem definitions! I've attended any programming contest back in Bulgaria and I can't recall anything that required me to read everything carefully 2-3 times before I get what needs to be done (oh, well, I wasn't 48 back then). I also got fascinated by GitHub Copilot, which actually autocompleted many of those missing basics and surprisingly "guessed" what I was trying to accomplished and offer meaningful productivity boost. I also looked into Zig, but, honestly, I didn't like many of the syntax choices made. Instead, I installed V [0], and will actually try to use it as it fits me better.

[0] https://vlang.io/

Failing to Learn Zig via Advent of Code

Related Stories