20 ms·

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://ne

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And it seems like they're planning to double down on this by making you adjust even more trivial things like public/private and var/const before it will even compile your code. https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/224 https://github.com/ziglang/zig/issues/224 Maybe I'm a bad developer, but my code is never perfect the first time around. I always spend time experimenting and refining my designs. I want to find a design that works, and only then spend time polishing and prettifying before I git push. I do understand the reasoning (they don't want people committing poor quality code), but this implementation just seems completely backwards to me. It breaks the natural order. It's like saying we won't let you ctrl+s until your tests pass to make sure you don't commit broken code. Stop nannying me and let me get my work done!

ArrayBoundCheck 4y ago
That was my problem with it. That and being mildly annoyed the creator hates tabs
- LAC-Tech 4y ago
  Thankfully the tabs thing is not meant to be permanent.
j16sdiz 4y ago
You can always do ' _ = your_varible', don't have to comment individuals
- avgcorrection 4y ago
  That was the first suggestion that Kelley posted on the issue and judging by the reactions people weren’t happy with it.
  - masklinn 4y ago
    Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.
    - flumpcakes 4y ago
      It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable. Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising. If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable).
      - masklinn 4y ago
        > It is not useless though. True, it's actively harmful. > There is a big difference between an unused variable and explicitly defining an unused variable. Which is not helpful when you're only doing it to hide a compiler error foisted upon you. > Kelly is designing Zig to do nothing surprising or change things underneath you. Refusing to compile my code because I've an unused variable is certainly surprising. > If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising. > I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable). 1. that it's an error is the entire problem here 2. and as far as I'm concerned it's a ridiculously weak warning, if your standard is that no action should be useless you need an unused store error, which subsume unused variables
- dmytrish 4y ago
  That makes unused variables "used", which defeats the point of the check.
  - vinay_ys 4y ago
    Yep. Exactly. We want to be able to silence the compiler for a few iterations while the code is taking shape and then cleanup all the compiler lints in later iteration. In production CI pipeline, we can have all compiler lints on. This capability is very much needed to have a fast local dev iteration where compiler can assist but not impede.
    - simlevesque 4y ago
      Eslint has `// eslint-disable-next-line no-unused-variables`, it is very useful. I'd prefer `eslint-expect-error-next-line` instead to warm me when the comment is actually useless but it's better than what Zig seem to do.
      - TakeBlaster16 4y ago
        There's a nice eslint plugin for disable-line hygiene: https://www.npmjs.com/package/eslint-plugin-eslint-comments https://www.npmjs.com/package/eslint-plugin-eslint-comments I do wish Rust had something like this too
        steveklabnik 4y ago
        https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=be54d7e9501361d3f93d3dfe56252ef9 https://play.rust-lang.org/?version=stable&mode=debug&editio... You can put it at the top of your file with a #! too, if you want it to apply to the whole file.
        TakeBlaster16 4y ago
        Oops I didn't explain clearly. Take this code: pub fn abc() -> usize { #[allow(deprecated)] "abc".len() } I want it to complain about the "allow", because there was never any deprecated warning emitted in the first place. Maybe it would be called #[expect(deprecated)] I refactor code all the time and find these stray "allow"s that aren't doing anything anymore
jstrong 4y ago
100% agree, do not understand the resistance to adding a flag or other way to temporarily disable that.
masklinn 4y ago
> I do understand the reasoning (they don't want people committing poor quality code) Not that this lint actually achieves that, or even prevents real errors. Go has the same, and it's so simplistic as to only be annoying. For instance not sure whether this fails in Zig but Go will allow this: v1, err := Foo() if err != nil { return nil, err } v2, err := Bar(v1) return v2, nil Error of second call is never checked, but go has no issue with that, because it only tracks definitions per use. v1, err := Foo() v2, err := Bar(v1) if err != nil { return nil, err } return v2, nil also works fine, despite probably sending complete nonsense to Bar, for the same reason. But then it's an absolute pain in the ass every time you're fucking around and stop using a debug import or whatever.
- llimllib 4y ago
  This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. The missing error checks are annoying, but if you have appropriate editor config it is hard to miss them: https://cdn.billmill.org/static/newsyctmp/warning.png https://cdn.billmill.org/static/newsyctmp/warning.png Basically writing go without `staticcheck`[1] is not recommended. If you do have it set up, it's pretty easy to avoid simple errors like that. I do wish the compiler checked it for you. [1]: https://staticcheck.io/ https://staticcheck.io/
  - masklinn 4y ago
    > This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. Don’t get me wrong I like a good unused code warning. What frustrates me is that Go’s is dumb / unreliable, and it will stop you from working entirely until you’ve complied with this whim, which has a fraction of a percent chance of identifying a real bug. > Basically writing go without `staticcheck`[1] is not recommended. So why have these things as mandatory compiler errors?
    - mirekrusin 4y ago
      So you don't publish it. I guess they could have levels and allow them in debug mode or with special flag or something?
WalterBright 4y ago
There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying. But most everyone else likes this, so it stays in. There are no real right answers here. Adding a switch for it just brings its own annoyance (every compiler switch is a bug). You just wind up settling for a local optimum.
- politician 4y ago
  Have you considered adding a dedicated `breakpoint` keyword for this use case? Linters could ignore it, but the compiler could warn or error. The problem with workarounds like `assert(0)` is that the linter lacks context to do the right thing.
  - WalterBright 4y ago
    Adding another feature is always tempting, and there are daily new feature requests for D. We simply have to have a very high bar for new features.
    - cxr 4y ago
      It's a good principle to pursue. But additional language features for production codebases vs toolchain features that happen to lean on changes to the language as a matter of UI are worth considering separately.
- oconnor663 4y ago
  > every compiler switch is a bug I totally get where this is coming from, but on the other hand it seems like Rust and Zig both get a lot of value from having the compiler understand the difference between debug and release modes, and it seems like modern C++ suffers somewhat from not having any built-in way to do something similar. The optimal number of compiler switches might not be zero.
wyldfire 4y ago
> I do understand the reasoning (they don't want people committing poor quality code), but this implementation just seems completely backwards to me. It breaks the natural order. It's like saying we won't let you ctrl+s until your tests pass to make sure you don't commit broken code. Stop nannying me and let me get my work done! Could it be that this problem is due to Zig's stance on "no warnings"? It's admirable to try and partition things into strict "correct" and "incorrect" categories. But with only static information it seems like there's always things that seem a little grey.
ptato 4y ago
There's a lot of people in the community that feel this way as well but tolerate it. I think it's a certainty that whenever zig 1.0 arrives it will immediately be forked to turn the unused errors into warnings, at least for debug mode. Another situation where I think the compiler is too eager with errors: unreachable code. A bare `@panic("")` won't compile, but you can "turn off" the error by doing `if (true) @panic("")`.
- sph 4y ago
  IIRC there's already a Zig fork that turns that abomination off. I remember seeing it mentioned in that upstream issue OP mentioned.
  - LAC-Tech 4y ago
    Do you remember the name or have a link?
    - strager 4y ago
      Maybe this: https://github.com/ziglang/zig/issues/335#issuecomment-1013800916 https://github.com/ziglang/zig/issues/335#issuecomment-10138...
amelius 4y ago
Yes, the linting should be in the git-commit code, not in the compiler.
linspace 4y ago
Refusing to compile takes the position that the compiler knows more than the developers. Or maybe are the compiler writers thinking they are the ones that know more? Maybe I'm being biased because I could consider using it in my free time and I already have enough bondage at work
- bluGill 4y ago
  When the code is "done" then I want the compiler to apply those strict checks and refuse to compile because of such issues. Every issue raised above is something that has come back to bite me in some bug later when not fixed. However like the others, I often do make a change for test purposes that I just want to see if it changes (not to be confused with fix!) the current issue, once I understand the problem better and have the right fix I will go back and clean it up, but right now I don't care about those little details when the big picture is wrong. In particular I often write code with TDD, once the current code passes the existing tests I'm going to add more code and then I'll need the thing the compiler is complaining about.
alpaca128 4y ago
This also makes learning Zig frustrating for people who aren't yet used to this low-level programming style. I gave up after a couple hours because it felt like I wasted half the time commenting and uncommenting code to avoid this error. People will always find ways to circumvent safety measures anyway, warnings are just fine for the developers who care.
sph 4y ago
You and me both, in fact I made my voice heard in the Github issue. What's damning is how much Stockholm Syndrome there is around this feature, with people saying it's no big deal and it helps catch bugs. It's more annoying than helpful, and it catches a very small amount of corner cases, while completely killing productivity. And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a massive undertaking to add warnings to a compiler. What a sorry excuse. I have ranted about this before, so I already feel my blood pressure going up.
- ok_dad 4y ago
  So don't use Zig? I don't get why you're so angry about something someone else likes. Just don't use it or look at it! So easy...
  - RussianCow 4y ago
    If I didn't use any programming language that I hated any part of, I wouldn't be able to write code.
  - md224 4y ago
    What if the person you're replying to really, really likes Zig except for this one aspect of it?
    - ok_dad 4y ago
      Then they shouldn't get so mad at something that's merely annoying; it's bad for the heart and circulatory system.
      - geodel 4y ago
        Yeah, exactly right! I mean we all adjust people, places, things all the time. There is nothing special about programing languages that it has to be perfect fit for each feature one desires.
      - runald 4y ago
cztomsik 4y ago
had the same problem, if you're just prototyping, it's easy to silence that with _ = someVar you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before.
- pcwalton 4y ago
  > you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before. They aren't comparable. Everything you mentioned in Rust is necessary for typechecking. Unused variable lints aren't necessary for anything.
  - cztomsik 4y ago
    I understand why is that needed. I am saying that prototyping (for me) is much easier in Zig. Some people like to define all the types (and traits) first, if it works for them then it's ok. I like to get feedback on something working as soon as possible because I'm likely a bit wrong and I will need to refine or rethink the whole thing again, rust is putting obstacles in my way, Zig is not.
delijati 4y ago
Yeah i run into the same issue, but the worst part of it, it wasn't my code i added a library and the compiler complaint unreachable code there oO
p0nce 4y ago
That's a reason why D's default are permissive. You add this or that constraints later, as needed.
errantmind 4y ago
I commented on the github issue a while back as I was frustrated with this. I originally looked forward to splitting my projects between Zig and Rust depending on the project parameters, but because of this one seemingly small issue I will never use Zig. That's ok, I respect them having the right to do what they want with their language but it is a little sad because I liked pretty much everything else about Zig.
LAC-Tech 4y ago
This 100%. I love Zig. It's built on such a better foundation than any of its competitors, old or new. I've never been happier or more productive doing systems programming. But the "no warnings" philosophy alienates developers and seriously hurts adoption. It's almost tragic that a language so impressive is going to die on this hill.
- KerrAvon 4y ago
  This sort of overopinionated design is part of what killed Phabricator. Let me customize the phucking thing a little bit. "No, we're doing opinionated design, and it's our rubber ducky."
laserbeam 4y ago
I'll be honest, it's one of those things that sounds alienating and painful. I am only going to talk about my experience with warnings in general to explain why I support that design. I had to work in python for a long time where code tends to be incredibly relaxed. When I switched to strict mypy typechecking at every build I became much much more productive and found and fixed dozens of bugs way earlier in development. I now am worried about all warnings and always strive to fix them. I am also making an analogy to "not being allowed to smoke indoors" when I see these complaints. People hated those laws when they were first proposed but everyone's cool with having to do a tiny bit work for health and safety. We'll see how communities play out, but I'm all for being rigorous.
thayne 4y ago
My typical approach to warnings and lints is to treat them as fatal, and if there is a good reason to ignore it, specifically silence it for that specific instance, with a comment on why it is ok. It really irks me when there isn't a way to have granular control over silencing warnings.

ArrayBoundCheck 4y ago

That was my problem with it. That and being mildly annoyed the creator hates tabs

LAC-Tech 4y ago
Thankfully the tabs thing is not meant to be permanent.

j16sdiz 4y ago

You can always do ' _ = your_varible', don't have to comment individuals

avgcorrection 4y ago
That was the first suggestion that Kelley posted on the issue and judging by the reactions people weren’t happy with it.
- masklinn 4y ago
  Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.
  - flumpcakes 4y ago
    It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable. Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising. If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable).
    - masklinn 4y ago
      > It is not useless though. True, it's actively harmful. > There is a big difference between an unused variable and explicitly defining an unused variable. Which is not helpful when you're only doing it to hide a compiler error foisted upon you. > Kelly is designing Zig to do nothing surprising or change things underneath you. Refusing to compile my code because I've an unused variable is certainly surprising. > If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising. > I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable). 1. that it's an error is the entire problem here 2. and as far as I'm concerned it's a ridiculously weak warning, if your standard is that no action should be useless you need an unused store error, which subsume unused variables
dmytrish 4y ago
That makes unused variables "used", which defeats the point of the check.
- vinay_ys 4y ago
  Yep. Exactly. We want to be able to silence the compiler for a few iterations while the code is taking shape and then cleanup all the compiler lints in later iteration. In production CI pipeline, we can have all compiler lints on. This capability is very much needed to have a fast local dev iteration where compiler can assist but not impede.
  - simlevesque 4y ago
    Eslint has `// eslint-disable-next-line no-unused-variables`, it is very useful. I'd prefer `eslint-expect-error-next-line` instead to warm me when the comment is actually useless but it's better than what Zig seem to do.
    - TakeBlaster16 4y ago
      There's a nice eslint plugin for disable-line hygiene: https://www.npmjs.com/package/eslint-plugin-eslint-comments https://www.npmjs.com/package/eslint-plugin-eslint-comments I do wish Rust had something like this too
      - steveklabnik 4y ago
        https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=be54d7e9501361d3f93d3dfe56252ef9 https://play.rust-lang.org/?version=stable&mode=debug&editio... You can put it at the top of your file with a #! too, if you want it to apply to the whole file.
        TakeBlaster16 4y ago
        Oops I didn't explain clearly. Take this code: pub fn abc() -> usize { #[allow(deprecated)] "abc".len() } I want it to complain about the "allow", because there was never any deprecated warning emitted in the first place. Maybe it would be called #[expect(deprecated)] I refactor code all the time and find these stray "allow"s that aren't doing anything anymore

jstrong 4y ago

100% agree, do not understand the resistance to adding a flag or other way to temporarily disable that.

masklinn 4y ago

> I do understand the reasoning (they don't want people committing poor quality code) Not that this lint actually achieves that, or even prevents real errors. Go has the same, and it's so simplistic as to only be annoying. For instance not sure whether this fails in Zig but Go will allow this: v1, err := Foo() if err != nil { return nil, err } v2, err := Bar(v1) return v2, nil Error of second call is never checked, but go has no issue with that, because it only tracks definitions per use. v1, err := Foo() v2, err := Bar(v1) if err != nil { return nil, err } return v2, nil also works fine, despite probably sending complete nonsense to Bar, for the same reason. But then it's an absolute pain in the ass every time you're fucking around and stop using a debug import or whatever.

llimllib 4y ago
This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. The missing error checks are annoying, but if you have appropriate editor config it is hard to miss them: https://cdn.billmill.org/static/newsyctmp/warning.png https://cdn.billmill.org/static/newsyctmp/warning.png Basically writing go without `staticcheck`[1] is not recommended. If you do have it set up, it's pretty easy to avoid simple errors like that. I do wish the compiler checked it for you. [1]: https://staticcheck.io/ https://staticcheck.io/
- masklinn 4y ago
  > This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. Don’t get me wrong I like a good unused code warning. What frustrates me is that Go’s is dumb / unreliable, and it will stop you from working entirely until you’ve complied with this whim, which has a fraction of a percent chance of identifying a real bug. > Basically writing go without `staticcheck`[1] is not recommended. So why have these things as mandatory compiler errors?
  - mirekrusin 4y ago
    So you don't publish it. I guess they could have levels and allow them in debug mode or with special flag or something?

WalterBright 4y ago

There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying. But most everyone else likes this, so it stays in. There are no real right answers here. Adding a switch for it just brings its own annoyance (every compiler switch is a bug). You just wind up settling for a local optimum.

politician 4y ago
Have you considered adding a dedicated `breakpoint` keyword for this use case? Linters could ignore it, but the compiler could warn or error. The problem with workarounds like `assert(0)` is that the linter lacks context to do the right thing.
- WalterBright 4y ago
  Adding another feature is always tempting, and there are daily new feature requests for D. We simply have to have a very high bar for new features.
  - cxr 4y ago
    It's a good principle to pursue. But additional language features for production codebases vs toolchain features that happen to lean on changes to the language as a matter of UI are worth considering separately.
oconnor663 4y ago
> every compiler switch is a bug I totally get where this is coming from, but on the other hand it seems like Rust and Zig both get a lot of value from having the compiler understand the difference between debug and release modes, and it seems like modern C++ suffers somewhat from not having any built-in way to do something similar. The optimal number of compiler switches might not be zero.

wyldfire 4y ago

> I do understand the reasoning (they don't want people committing poor quality code), but this implementation just seems completely backwards to me. It breaks the natural order. It's like saying we won't let you ctrl+s until your tests pass to make sure you don't commit broken code. Stop nannying me and let me get my work done! Could it be that this problem is due to Zig's stance on "no warnings"? It's admirable to try and partition things into strict "correct" and "incorrect" categories. But with only static information it seems like there's always things that seem a little grey.

ptato 4y ago

There's a lot of people in the community that feel this way as well but tolerate it. I think it's a certainty that whenever zig 1.0 arrives it will immediately be forked to turn the unused errors into warnings, at least for debug mode. Another situation where I think the compiler is too eager with errors: unreachable code. A bare `@panic("")` won't compile, but you can "turn off" the error by doing `if (true) @panic("")`.

sph 4y ago
IIRC there's already a Zig fork that turns that abomination off. I remember seeing it mentioned in that upstream issue OP mentioned.
- LAC-Tech 4y ago
  Do you remember the name or have a link?
  - strager 4y ago
    Maybe this: https://github.com/ziglang/zig/issues/335#issuecomment-1013800916 https://github.com/ziglang/zig/issues/335#issuecomment-10138...

amelius 4y ago

Yes, the linting should be in the git-commit code, not in the compiler.

linspace 4y ago

Refusing to compile takes the position that the compiler knows more than the developers. Or maybe are the compiler writers thinking they are the ones that know more? Maybe I'm being biased because I could consider using it in my free time and I already have enough bondage at work

bluGill 4y ago
When the code is "done" then I want the compiler to apply those strict checks and refuse to compile because of such issues. Every issue raised above is something that has come back to bite me in some bug later when not fixed. However like the others, I often do make a change for test purposes that I just want to see if it changes (not to be confused with fix!) the current issue, once I understand the problem better and have the right fix I will go back and clean it up, but right now I don't care about those little details when the big picture is wrong. In particular I often write code with TDD, once the current code passes the existing tests I'm going to add more code and then I'll need the thing the compiler is complaining about.

alpaca128 4y ago

This also makes learning Zig frustrating for people who aren't yet used to this low-level programming style. I gave up after a couple hours because it felt like I wasted half the time commenting and uncommenting code to avoid this error. People will always find ways to circumvent safety measures anyway, warnings are just fine for the developers who care.

sph 4y ago

You and me both, in fact I made my voice heard in the Github issue. What's damning is how much Stockholm Syndrome there is around this feature, with people saying it's no big deal and it helps catch bugs. It's more annoying than helpful, and it catches a very small amount of corner cases, while completely killing productivity. And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a massive undertaking to add warnings to a compiler. What a sorry excuse. I have ranted about this before, so I already feel my blood pressure going up.

ok_dad 4y ago
So don't use Zig? I don't get why you're so angry about something someone else likes. Just don't use it or look at it! So easy...
- RussianCow 4y ago
  If I didn't use any programming language that I hated any part of, I wouldn't be able to write code.
- md224 4y ago
  What if the person you're replying to really, really likes Zig except for this one aspect of it?
  - ok_dad 4y ago
    Then they shouldn't get so mad at something that's merely annoying; it's bad for the heart and circulatory system.
    - geodel 4y ago
      Yeah, exactly right! I mean we all adjust people, places, things all the time. There is nothing special about programing languages that it has to be perfect fit for each feature one desires.
    - runald 4y ago

cztomsik 4y ago

had the same problem, if you're just prototyping, it's easy to silence that with _ = someVar you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before.

pcwalton 4y ago
> you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before. They aren't comparable. Everything you mentioned in Rust is necessary for typechecking. Unused variable lints aren't necessary for anything.
- cztomsik 4y ago
  I understand why is that needed. I am saying that prototyping (for me) is much easier in Zig. Some people like to define all the types (and traits) first, if it works for them then it's ok. I like to get feedback on something working as soon as possible because I'm likely a bit wrong and I will need to refine or rethink the whole thing again, rust is putting obstacles in my way, Zig is not.

delijati 4y ago

Yeah i run into the same issue, but the worst part of it, it wasn't my code i added a library and the compiler complaint unreachable code there oO

p0nce 4y ago

That's a reason why D's default are permissive. You add this or that constraints later, as needed.

errantmind 4y ago

I commented on the github issue a while back as I was frustrated with this. I originally looked forward to splitting my projects between Zig and Rust depending on the project parameters, but because of this one seemingly small issue I will never use Zig. That's ok, I respect them having the right to do what they want with their language but it is a little sad because I liked pretty much everything else about Zig.

LAC-Tech 4y ago

This 100%. I love Zig. It's built on such a better foundation than any of its competitors, old or new. I've never been happier or more productive doing systems programming. But the "no warnings" philosophy alienates developers and seriously hurts adoption. It's almost tragic that a language so impressive is going to die on this hill.

KerrAvon 4y ago
This sort of overopinionated design is part of what killed Phabricator. Let me customize the phucking thing a little bit. "No, we're doing opinionated design, and it's our rubber ducky."

laserbeam 4y ago

I'll be honest, it's one of those things that sounds alienating and painful. I am only going to talk about my experience with warnings in general to explain why I support that design. I had to work in python for a long time where code tends to be incredibly relaxed. When I switched to strict mypy typechecking at every build I became much much more productive and found and fixed dozens of bugs way earlier in development. I now am worried about all warnings and always strive to fix them. I am also making an analogy to "not being allowed to smoke indoors" when I see these complaints. People hated those laws when they were first proposed but everyone's cool with having to do a tiny bit work for health and safety. We'll see how communities play out, but I'm all for being rigorous.

thayne 4y ago

My typical approach to warnings and lints is to treat them as fatal, and if there is a good reason to ignore it, specifically silence it for that specific instance, with a comment on why it is ok. It really irks me when there isn't a way to have granular control over silencing warnings.