This contrasts to Rust, which leads programmers to insert panics into their code.
Inserting panics is definitely not the norm.
In Rust you can use ?, which is quicker than unwrap, but you also have to do something like Result<Type, Box<dyn std::error::Error>. That's a mouthful! Alternatively, you can use the anyhow crate and return anyhow::Result, which also provides some nice helper methods. But then you have to add a dependency for reasonable error handling. There's also Zig-style composable errors with yet another library.
You definitely don't have to return a boxed error. In fact I consider that a code smell. The alternative not discussed here is to define your error enum like you would with thiserror and then implement the Error trait yourself. This is totally doable, and not that much of a pain if you're wanting to avoid a dependency.
Nitpicks aside, one of the things I struggle with in Zig sometimes is that starting a new project can be a worst case scenario for an ADHD brain. When I'm starting a new project I want to jump right in to tinkering on the problem, and instead I find myself wiring up similar functionality in build.zig that I use in many projects (check step to help out ZLS, test steps, etc). By the time I'm satisfied with my build.zig I've already spent a chunk of my dopamine budget on working through a part of the project I find aggressively uninteresting 😅
Anyway, @liberty definitely come say hi in Portland :)
It's common to panic when prototyping, since it's the easiest way to handle errors. Sometimes these remain in production code because it's easy to forget about them. This is worsened when there are many examples online that both train new developers and LLMs how to write code.
I've seen Rust panics in apps I've used regularly and also have seen expect abused to produce error messages (I've done this when prototyping, so I'm also guilty).
In Zig, on the other hand, the easiest way to handle errors is to bubble them up. This is much easier to add proper error handling to later on, and doesn't crash the whole application.
You definitely don't have to return a boxed error. In fact I consider that a code smell. The alternative not discussed here is to define your error enum like you would with thiserror and then implement the Error trait yourself. This is totally doable, and not that much of a pain if you're wanting to avoid a dependency.
I have done this before. It's much more annoying to do than in Zig and doesn't handle composition nearly as cleanly.
.. sometimes is that starting a new project can be a worst case scenario for an ADHD brain ...
That's fair. Have you considered having a basic build.zig you use for your projects? Copy/paste is the time-old solution to boilerplate after all. I'm curious if there's anything that's specific to each project that prevents that. Maybe it'd be a good feature to have in ZLS?
Anyway, @liberty definitely come say hi in Portland :)
It's a bit of a trip but I'll definitely have to sometime!
Sometimes these remain in production code because it's easy to forget about them.
If one is through with the prototyping stage and doesn't want to grep for unwrap( or expect(, the Clippy lints "unwrap_used" and "expect_used" will forbid these automatically.
I use Clippy this way liberally. Unfortunately there's a whole ecosystem to consider that may not.
Also, it's generally the case that the code that is written first tends to be the code that remains (which is why TigerStyle emphasizes getting things right the first time).
To get things right the first time is not actionable advice, as no one endeavors to get things wrong. To gradually increase the level of confidence in a code base over time we gradually increase the level of rigor to which we subject it, which includes increasing the scope of static analysis once code is no longer in the prototyping phase, easily done via automatic enforcement in CI.
This is answered in the article. It boils down to:
Most dependencies have many more dependencies
Rust's standard library doesn't include essential functionality that many projects depend on
It's possible but painful to make Rust work without large dependency trees. I do hope for the Rust ecosystem to make strides in a better direction here like they are in other places.
Zig avoids both through dependency culture and having basic stuff like error handling and serialization in the language or standard library.
I do hope for the Rust ecosystem to make strides in a better direction here like they are in other places.
Amen to that! As a heavy Rust user and longtime fan, the current dependency situation (and culture) is maybe my biggest annoyance with the language/ecosystem.
I was going to ask what Zig has that Rust doesn't (genuine question, I have not spent much time with Zig yet). I'm surprised you say error handling, but serialization is a big one!
It's nice to see a second blog post on a positive experience from the last Zig Day Seattle. Positive feedback keeps these events happening, not that they're hard to organize once you've found a location that works.
I may even head down to Portland to catch one before the next local one comes around.
This is certainly do-able with the next Zig Day Portland being on Novemeber 7th, but the next Zig Day Seattle is the very next day on November 8th, so it's not like you'd have to wait long. If this post piques anyone's interest in Zig and the Bellevue library isn't a hard place to get to, please join us as newbies are more than welcome! I made sure we got the big room this time just in case, hah.
zmitchell | 9 hours ago
Inserting panics is definitely not the norm.
You definitely don't have to return a boxed error. In fact I consider that a code smell. The alternative not discussed here is to define your error enum like you would with
thiserrorand then implement theErrortrait yourself. This is totally doable, and not that much of a pain if you're wanting to avoid a dependency.Nitpicks aside, one of the things I struggle with in Zig sometimes is that starting a new project can be a worst case scenario for an ADHD brain. When I'm starting a new project I want to jump right in to tinkering on the problem, and instead I find myself wiring up similar functionality in
build.zigthat I use in many projects (checkstep to help out ZLS,teststeps, etc). By the time I'm satisfied with mybuild.zigI've already spent a chunk of my dopamine budget on working through a part of the project I find aggressively uninteresting 😅Anyway, @liberty definitely come say hi in Portland :)
liberty | 7 hours ago
It's common to panic when prototyping, since it's the easiest way to handle errors. Sometimes these remain in production code because it's easy to forget about them. This is worsened when there are many examples online that both train new developers and LLMs how to write code.
I've seen Rust panics in apps I've used regularly and also have seen
expectabused to produce error messages (I've done this when prototyping, so I'm also guilty).In Zig, on the other hand, the easiest way to handle errors is to bubble them up. This is much easier to add proper error handling to later on, and doesn't crash the whole application.
I have done this before. It's much more annoying to do than in Zig and doesn't handle composition nearly as cleanly.
That's fair. Have you considered having a basic
build.zigyou use for your projects? Copy/paste is the time-old solution to boilerplate after all. I'm curious if there's anything that's specific to each project that prevents that. Maybe it'd be a good feature to have in ZLS?It's a bit of a trip but I'll definitely have to sometime!
ghoti | 6 hours ago
If one is through with the prototyping stage and doesn't want to grep for
unwrap(orexpect(, the Clippy lints "unwrap_used" and "expect_used" will forbid these automatically.liberty | 5 hours ago
I use Clippy this way liberally. Unfortunately there's a whole ecosystem to consider that may not.
Also, it's generally the case that the code that is written first tends to be the code that remains (which is why TigerStyle emphasizes getting things right the first time).
ghoti | 2 hours ago
To get things right the first time is not actionable advice, as no one endeavors to get things wrong. To gradually increase the level of confidence in a code base over time we gradually increase the level of rigor to which we subject it, which includes increasing the scope of static analysis once code is no longer in the prototyping phase, easily done via automatic enforcement in CI.
dmytrish | 12 hours ago
I'm wondering what prevents the author from stripping away dependencies in Rust.
liberty | 12 hours ago
This is answered in the article. It boils down to:
It's possible but painful to make Rust work without large dependency trees. I do hope for the Rust ecosystem to make strides in a better direction here like they are in other places.
Zig avoids both through dependency culture and having basic stuff like error handling and serialization in the language or standard library.
wofo | 10 hours ago
Amen to that! As a heavy Rust user and longtime fan, the current dependency situation (and culture) is maybe my biggest annoyance with the language/ecosystem.
casperin | 10 hours ago
I was going to ask what Zig has that Rust doesn't (genuine question, I have not spent much time with Zig yet). I'm surprised you say error handling, but serialization is a big one!
ScottRedig | 4 hours ago
It's nice to see a second blog post on a positive experience from the last Zig Day Seattle. Positive feedback keeps these events happening, not that they're hard to organize once you've found a location that works.
This is certainly do-able with the next Zig Day Portland being on Novemeber 7th, but the next Zig Day Seattle is the very next day on November 8th, so it's not like you'd have to wait long. If this post piques anyone's interest in Zig and the Bellevue library isn't a hard place to get to, please join us as newbies are more than welcome! I made sure we got the big room this time just in case, hah.