Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

61–70 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#61
post #50
post #27

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?

I can't put my finger on it. I love ruby, but often times digging deeper into Ruby source code, I would hit a point where I would think, "oh God, I give up, this is magic". Comparing it to elixir, my daily driver, is like night and day. Usually I can figure out what is happening (there are a few places, like Phoenix Routes and Ecto Query Builders where I have gotten stimied). Zig is even better - especially at the stdlib level

Re: Failing to Learn Zig via Advent of Code

#62
post #29

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…

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…

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?

Re: Failing to Learn Zig via Advent of Code

#63
post #37

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.

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.

Re: Failing to Learn Zig via Advent of Code

#64

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

Seriously, comparing by timeline like that is an unfair comparison. You should probably kick a few dollars into the zig foundation as penance for having made it publically. ;)

Re: Failing to Learn Zig via Advent of Code

#65
post #38

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

Re: Failing to Learn Zig via Advent of Code

#66

Earlier 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…

Well, the STD documentation page has a red banner saying it's experimental and you should consider reading the code (which worked great for me) so at least you have a warning.

Re: Failing to Learn Zig via Advent of Code

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

Re: Failing to Learn Zig via Advent of Code

#68
post #17

Earlier 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

Read The Fabulous Sources?

Re: Failing to Learn Zig via Advent of Code

#69

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

Rust was just some guy's project at first, much like Zig, and it started in 2006. It was barely alpha in 2012 and wasn't stable until 2015: and it had had corporate backing for six years at that point.

Patience.

Re: Failing to Learn Zig via Advent of Code

#70
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/

Post reply on HN