Hacker News Reader

Comment by alpaca128 | Hacker News Reader

I don't get what makes Zig errors better. As I understand it they're just named error codes with special syntax for handling them, meaning any more complex error type or any kind of contextual information has to be dealt with separately. If you want to return the location of a syntax error in the input you can't provide that information in the error. Zig has a couple opinionated properties I find strange, but the error handling is the one I find the most puzzling.

Meanwhile Rust treats all possible error types the same way as long as they're wrapped in Result.

View on HN

I think that like actually using Rust and encountering situations where one must define a new error enum that exists only to wrap the values returned by two different fallible functions belonging to different libraries all the time was sufficient to convince me that the situation in Zig is preferable. It's also generally good that users are unable to attach strings to their errors when using the built-in error handling, in the sense that things that are usually bad ideas ought to be a bit more difficult, so that users do not end up doing them all the time.

> in the sense that things that are usually bad ideas ought to be a bit more difficult,

I didn't know that the Zig folks had embraced the Go philosophy of “the language designer knows better than you” for trivial stuff like that.

That's the kind of behavior that lead people to build their own version of things, incompatible with the whole ecosystem, just to be free from the petty arbitrary limitation.

They also settled the tabs vs. spaces debate by declaring tabs a syntax error, end of discussion. Same with unused variables which are a compile-time error.

The thing is, I don't disagree with the fundamental arguments that led to these decisions, I just think it goes a step too far and they're trying too hard. I understand they aim to reduce footguns in C with that language but that doesn't mean they have to prevent someone from wearing the wrong shoe for the occasion.

> They also settled the tabs vs. spaces debate by declaring tabs a syntax error,

Did Zig really do that? Because even go didn't, it's just the default of gofmt and you can't override it, but not a hard error.

> Same with unused variables which are a compile-time error.

Which is a pain in the ass for anyone attempting to refactor or iterate on a go codebase. A warning is just the better option for this kind of things. That's the entire purpose of the concept of warning.

https://github.com/ziglang/zig/issues/544#issuecomment-61807...

> In order to simplify everything, tabs are not allowed. Spaces are necessary; we can't ban spaces.

They seem to be open to the alternative but not to a solution that isn't forced on people:

> Maybe someday, we'll switch to tabs for indentation, spaces for alignment and make it a compile error if they are incorrectly mixed

Zig already has a builtin code formatter that automatically changes formatting to their preference, but that's not enough.

> That's the entire purpose of the concept of warning

Yes, but as far as I know the Zig compiler cannot emit warnings, only errors. Because warnings are potential footguns too and we can't have that.

Ugh.

Thanks nonetheless.

> Yes, but as far as I know the Zig compiler cannot emit warnings, only errors. Because warnings are potential footguns too and we can't have that.

Okay they're kind of on to something here, because in my experience with C, warnings just get ignored. And you only get warning if you're doing something really suspicious in the first place.

Every serious C project I've worked on has used -Werror.

> Every serious C project I've worked on has used -Werror.

-Werror is a good default for CI, but not for local development.

Yeah I would agree, same with unused variables.

I 100% understand the motivation and agree with it. But an optional compiler flag would be nice for development, instead of the special syntax that has to be applied per unused identifier.

And I just don't get why the compiler has to throw an error about a formatting preference when the builtin formatter already changes it accordingly. Any serious project can just mandate use of the formatter to keep things consistent and be done with it. Instead the github issues have people debate tabs vs spaces because the compiler took a side in order to end the "bikeshed of all bikesheds", ironically contributing to it.

> one must define a new error enum that exists only to wrap the values returned by two different fallible functions belonging to different libraries

Saying this must be done is awfully strong here. There are other tools at your disposal, like dyn Error and the anyhow crate.

It "must" be done in the sense that `dyn Error`, anyhow, and (if we include zig's equivalent) inferred error sets mean something different than setting up an error enum. Using an error enum makes the failures explicit, which (most) other options choose to discard because they're designed to handle any error.

Your options effectively become either writing that enum, or using a macro that reduces to that enum. Unless, of course, you're willing to have the function signature say "eh, this function just breaks sometimes. Could be anything really."

Reply on news.ycombinator.com