Earlier quoted context omitted.
In general I would agree, but (as multiple people pointed out) the zig standard library source code is very accessible.
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?
Failing to Learn Zig via Advent of Code
61–70 of 338 posts
Re: Failing to Learn Zig via Advent of Code
#62As 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…
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…
A lot of this seems to be a mismatch between people's expectations of zig's stability and the reality?
Re: Failing to Learn Zig via Advent of Code
#63It'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.
Re: Failing to Learn Zig via Advent of Code
#64Earlier quoted context omitted.
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).
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.
Re: Failing to Learn Zig via Advent of Code
#65> [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?
I think that's why he would like a `zig check` command that would give him these errors and warnings faster.
Re: Failing to Learn Zig via Advent of Code
#66Earlier quoted context omitted.
Zig absolutely has documentation: https://ziglang.org/documentation/master/
That's the language reference, that also links the experimental autogenerated std documentation Right now, Zig is young and the documentation is kinda ok (Language reference is clear enough, outside a few things that need better visibility, for example, explaining concepts that are only on the examples can be lost easy), the autogenerated std on the other hand used to work meh, until a commit broke it afaik, so rn is…
Re: Failing to Learn Zig via Advent of Code
#67I 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
and, as the author metioned, Zig Learn is by far the closest thing we have to a "Zig book".
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.
Re: Failing to Learn Zig via Advent of Code
#68Earlier quoted context omitted.
Recommended way to learn for now? Any sources for that?
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
Re: Failing to Learn Zig via Advent of Code
#69Earlier quoted context omitted.
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).
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.
Patience.
Re: Failing to Learn Zig via Advent of Code
#70At 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/