Failing to Learn Zig via Advent of Code

literally only you introduced this 'looking for a supplier right now' concept. I hope you enjoyed knocking down this strawman.

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

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.

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.

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

> Seriously, comparing by timeline like that is an unfair comparison.

The article is about failing to learn right now. The first comment was about the absence of documentation right now. You're defending Zig being worse than other languages by saying that Zig is younger, which is a fair point. But you also said that comparing by timelines is unfair, which I think is wrong, which is why we're having this conversation. My point is that comparing by timeline is totally fair, because people are evaluating a language on what it is, and not what it can be.

To speak in more precise terms: the current position of Zig is worse than other languages, especially in terms of documentation. The position adjusted for the timeline of Zig is also worse than many other languages at that point. You're asking us to not compare by position or position adjusted for the timeline, but by position relative to the ressources invested, and/or position adjusted for the timeline relative to the ressources invested. I'm saying that this comparaison is useless, because 1) those relation doesn't scale linearly, and 2) because people are interested in the actual position and position adjusted for the timeline, not the efficiency.

Since you reject comparing the evolution of the documentation of Zig through time ("Seriously, comparing by timeline like that is an unfair comparison.") and right now ("It's important to consider that for zig at this stage, "not having valid documentation" is expected."), your only argument seems to be about the future: "At some point not having valid docs will become considered to be unacceptable.". The vast majority of people, when faced with a language that looks not great at the moment but could have a bright future, will react with "I'll take a look again in a year or two". You argue for the opposite, that people should contribute to Zig instead: "You should probably kick a few dollars into the zig foundation as penance for having made it publically. ;)". That is a weak point, and won't convince the people that have seen languages come and go. Especially these days when new languages have great documentation, error messages, and onboarding in general.

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.