5 ms·

I find the Zig example to be shocking. It's just so brittle. How can anyone think this is a good idea?

by veber-alex 1y ago

zparky 1y ago
I didn't even see the error after the first glance until I read your comment.
- veber-alex 1y ago
  Yeah, I had to do a double take while reading the article because I missed the error completely while looking at the code.
- WD-42 1y ago
  I saw this comment first and then read the zig and still couldn’t find the error until I read the explanation below it. This has to be a bug.
tialaramex 1y ago
I assume it's a bug. However because this is an auteur language if you want the bug fixed it will be important to ensure the auteur also thinks it is a bug. If they get it into their head that it's supposed to be like this, they'll double down and regardless of how many people are annoyed they're insist on it.
- veber-alex 1y ago
  Knowing how the Zig developers operate it's 100% not a bug and it's exactly the case you described.
- ozgrakkurt 1y ago
  Tbh you would just use ErrorTypeName.ErrorKind to check equality and not error.ErrorKind if you are worried about this. It is a tradeoff between making some things easier. And probably compiler is not mature enough to catch this mistake yet but it will be at some point. Zig being an auteur language is a very good thing from my perspective, for example you get this new IO approach which is amazing and probably wouldn’t happen if Andrew Kelley wasn’t in the position he is in. I have been using Rust to write storage engines past couple years and it’s async and io systems have many performance mistakes. Whole ecosystem feels like it is basically designed for writing web servers. An example is a file format library using Io traits everywhere and using buffered versions for w/e reason. Then you get a couple extra memcopy calls that are copying huge buffers. Combined with global allocation everywhere approach, it generates a lot of page faults which tanks performance. Another example was, file format and just compute libraries using asyncio traits everywhere which forces everything to be send+sync+’static which makes it basically impossible to use in single thread context with local allocators. Another example is a library using vec everywhere even if they know what size they’ll need and generating memcopies as vec is getting bigger. Language just makes it too easy. I’m not saying Rust is bad, it is a super productive ecosystem. But it is good that Zig is able to go deeper and enable more things. Which is possible because one guy can just say “I’ll break the entire IO API so I can make it better”.
  - tialaramex 1y ago
    > if you are worried about this Obviously nobody knows they've made this mistake, that's why it is important for the compiler to reject the mistake and let you know. I don't want to use an auteur language, the fact is Andrew is wrong about some things - everybody is, but because it's Andrew's language too bad that's the end of the discussion in Zig. I like Rust's `break 'label value`. It's very rarely the right thing, but sometimes, just sometimes, it's exactly what you needed and going without is very annoying. However IIUC for some time several key Rust language people hated this language feature, so it was blocked from landing in stable Rust. If Rust was an auteur language, one person's opinion could doom that feature forever.
- jibal 1y ago
  Why would you assume that? It's very intentional design decision.
  - tialaramex 1y ago
    Because it's a foot gun. People are going to shoot themselves in the foot with this feature, and I'm generous enough to assume that was not desired which makes it a bug.
    - jibal 1y ago
      As others have noted, this is not idiomatic usage. But again, this is the design ... there's no bug. Languages are full of design decisions that may not be optimal in all usages ... that's different from bugs. Footguns breed bugs. Here's a page of non-bugs: https://www.reddit.com/r/ProgrammingLanguages/comments/1hd7llg/foot_guns_and_other_antipatterns/ https://www.reddit.com/r/ProgrammingLanguages/comments/1hd7l...
- Ericson2314 1y ago
  I'm smirking big time reading this :), well said (To be clear to others, it's not even that this is 100% a bad thing, but people love to shit on "design by committee" so much, it helps to have a bit of the opposite)
- gwenzek 1y ago
  Andrew actually agrees with the general sentiment. And this will be made into a compile error. What's happening is that compiler knows the two errors come from disjoint error set, but it promotes them both to anyerror Details at https://github.com/ziglang/zig/issues/25046 https://github.com/ziglang/zig/issues/25046
kouteiheika 1y ago
Every language has questionable design decisions that lead to brittle code, although some more than others. Like, how can anyone think that requiring the user to always remember to explicitly write `mutex.unlock()` or `defer mutex.unlock()` instead of just allowing optional explicit unlock and having it automatically unlock when it goes out of scope by default is a good idea? Both Go and Zig have this flaw. Or, how can anyone think that having a cast that can implicitly convert from any numeric type to any other in conjunction with pervasive type inference is a good idea, like Rust's terrible `as` operator? (I once spent a whole day debugging a bug due to this.)
- veber-alex 1y ago
  You are right, but it doesn't mean we can't complain about it :) As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition.
  - JoshTriplett 1y ago
    > As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition. Rust language hat on: I hope so too. We very much want to, once we've replaced its various use cases.
    - bigstrat2003 1y ago
      As a Rust user, I hope that "as" never goes away. It's way too useful to get rid of, e.g. deliberately truncating numbers to a smaller number of bits. Can you do that in other ways? Absolutely. But they are all less ergonomic than "as". At most I would be ok with restricting "as" to an unsafe block, though that isn't a perfect solution because unsafe isn't really meant to apply to such cases.
      - 1y ago
Phil_Latio 1y ago
I would've assumed the error set is generated based on function signatures. Sick stuff.
geysersam 1y ago
Can't a linter catch that you're referring to an error that doesn't exist anywhere else in your system and warn you about that and suggest you use switch instead of if?

I find the Zig example to be shocking. It's just so brittle. How can anyone think this is a good idea?

zparky 1y ago

I didn't even see the error after the first glance until I read your comment.

veber-alex 1y ago
Yeah, I had to do a double take while reading the article because I missed the error completely while looking at the code.
WD-42 1y ago
I saw this comment first and then read the zig and still couldn’t find the error until I read the explanation below it. This has to be a bug.

tialaramex 1y ago

I assume it's a bug. However because this is an auteur language if you want the bug fixed it will be important to ensure the auteur also thinks it is a bug. If they get it into their head that it's supposed to be like this, they'll double down and regardless of how many people are annoyed they're insist on it.

veber-alex 1y ago
Knowing how the Zig developers operate it's 100% not a bug and it's exactly the case you described.
ozgrakkurt 1y ago
Tbh you would just use ErrorTypeName.ErrorKind to check equality and not error.ErrorKind if you are worried about this. It is a tradeoff between making some things easier. And probably compiler is not mature enough to catch this mistake yet but it will be at some point. Zig being an auteur language is a very good thing from my perspective, for example you get this new IO approach which is amazing and probably wouldn’t happen if Andrew Kelley wasn’t in the position he is in. I have been using Rust to write storage engines past couple years and it’s async and io systems have many performance mistakes. Whole ecosystem feels like it is basically designed for writing web servers. An example is a file format library using Io traits everywhere and using buffered versions for w/e reason. Then you get a couple extra memcopy calls that are copying huge buffers. Combined with global allocation everywhere approach, it generates a lot of page faults which tanks performance. Another example was, file format and just compute libraries using asyncio traits everywhere which forces everything to be send+sync+’static which makes it basically impossible to use in single thread context with local allocators. Another example is a library using vec everywhere even if they know what size they’ll need and generating memcopies as vec is getting bigger. Language just makes it too easy. I’m not saying Rust is bad, it is a super productive ecosystem. But it is good that Zig is able to go deeper and enable more things. Which is possible because one guy can just say “I’ll break the entire IO API so I can make it better”.
- tialaramex 1y ago
  > if you are worried about this Obviously nobody knows they've made this mistake, that's why it is important for the compiler to reject the mistake and let you know. I don't want to use an auteur language, the fact is Andrew is wrong about some things - everybody is, but because it's Andrew's language too bad that's the end of the discussion in Zig. I like Rust's `break 'label value`. It's very rarely the right thing, but sometimes, just sometimes, it's exactly what you needed and going without is very annoying. However IIUC for some time several key Rust language people hated this language feature, so it was blocked from landing in stable Rust. If Rust was an auteur language, one person's opinion could doom that feature forever.
jibal 1y ago
Why would you assume that? It's very intentional design decision.
- tialaramex 1y ago
  Because it's a foot gun. People are going to shoot themselves in the foot with this feature, and I'm generous enough to assume that was not desired which makes it a bug.
  - jibal 1y ago
    As others have noted, this is not idiomatic usage. But again, this is the design ... there's no bug. Languages are full of design decisions that may not be optimal in all usages ... that's different from bugs. Footguns breed bugs. Here's a page of non-bugs: https://www.reddit.com/r/ProgrammingLanguages/comments/1hd7llg/foot_guns_and_other_antipatterns/ https://www.reddit.com/r/ProgrammingLanguages/comments/1hd7l...
Ericson2314 1y ago
I'm smirking big time reading this :), well said (To be clear to others, it's not even that this is 100% a bad thing, but people love to shit on "design by committee" so much, it helps to have a bit of the opposite)
gwenzek 1y ago
Andrew actually agrees with the general sentiment. And this will be made into a compile error. What's happening is that compiler knows the two errors come from disjoint error set, but it promotes them both to anyerror Details at https://github.com/ziglang/zig/issues/25046 https://github.com/ziglang/zig/issues/25046

kouteiheika 1y ago

Every language has questionable design decisions that lead to brittle code, although some more than others. Like, how can anyone think that requiring the user to always remember to explicitly write `mutex.unlock()` or `defer mutex.unlock()` instead of just allowing optional explicit unlock and having it automatically unlock when it goes out of scope by default is a good idea? Both Go and Zig have this flaw. Or, how can anyone think that having a cast that can implicitly convert from any numeric type to any other in conjunction with pervasive type inference is a good idea, like Rust's terrible `as` operator? (I once spent a whole day debugging a bug due to this.)

veber-alex 1y ago
You are right, but it doesn't mean we can't complain about it :) As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition.
- JoshTriplett 1y ago
  > As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition. Rust language hat on: I hope so too. We very much want to, once we've replaced its various use cases.
  - bigstrat2003 1y ago
    As a Rust user, I hope that "as" never goes away. It's way too useful to get rid of, e.g. deliberately truncating numbers to a smaller number of bits. Can you do that in other ways? Absolutely. But they are all less ergonomic than "as". At most I would be ok with restricting "as" to an unsafe block, though that isn't a perfect solution because unsafe isn't really meant to apply to such cases.
    - 1y ago

Phil_Latio 1y ago

I would've assumed the error set is generated based on function signatures. Sick stuff.

geysersam 1y ago

Can't a linter catch that you're referring to an error that doesn't exist anywhere else in your system and warn you about that and suggest you use switch instead of if?