Failing to Learn Zig via Advent of Code(forrestthewoods.com)
forrestthewoods.com
Failing to Learn Zig via Advent of Code
https://www.forrestthewoods.com/blog/failing-to-learn-zig-via-advent-of-code/
329 comments
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.
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.
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:
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.
> 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
template<typename T> T parseInt(const char buf[], uint8_t radix)
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.
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.
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.
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/
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/
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/
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/
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.
"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.
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.
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.
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.
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,)
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,)
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
https://github.com/ziglang/zig/tree/master/lib/std
> [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 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?
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:
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.
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.
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”
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.
Zig is far from a finished project so it's premature to complain about most of the things you are complaining about.
> 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.
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.
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.
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.
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.
Such usability reports are super informative for when you want to make software usable.
> 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-...
> 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-...
> 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
> 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
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:
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.
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.
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.
> 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?
Does that mean that someone at his office had better luck and should be writing the success article? Or something else?
> 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.
That's a bit overambitious maybe.
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/
[0]: https://vlang.io/
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.
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.
[deleted]
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.
Seems like the author isn't used to low-level programming languages. Zig is a great C replacement.
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.
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.