5 ms·

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 dif

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.

littlestymaar 1y ago
> 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.
- alpaca128 1y ago
  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.
  - littlestymaar 1y ago
    > 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.
    - alpaca128 1y ago
      https://github.com/ziglang/zig/issues/544#issuecomment-618072318 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.
      - littlestymaar 1y ago
        Ugh. Thanks nonetheless.
      - const_cast 1y ago
        > 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.
        littlestymaar 1y ago
        > Every serious C project I've worked on has used -Werror. -Werror is a good default for CI, but not for local development.
        const_cast 1y ago
        Yeah I would agree, same with unused variables.
        alpaca128 1y ago
kbolino 1y ago
> 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.
- kartoffelsaft 1y ago
  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."

littlestymaar 1y ago

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

alpaca128 1y ago
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.
- littlestymaar 1y ago
  > 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.
  - alpaca128 1y ago
    https://github.com/ziglang/zig/issues/544#issuecomment-618072318 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.
    - littlestymaar 1y ago
      Ugh. Thanks nonetheless.
    - const_cast 1y ago
      > 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.
      - littlestymaar 1y ago
        > Every serious C project I've worked on has used -Werror. -Werror is a good default for CI, but not for local development.
        const_cast 1y ago
        Yeah I would agree, same with unused variables.
      - alpaca128 1y ago

kbolino 1y ago

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

kartoffelsaft 1y ago
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."