Hacker News Reader

Comment by TakeBlaster16 | Hacker News Reader

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

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/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!

View on HN

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

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

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/

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

So you don't publish it.

I guess they could have levels and allow them in debug mode or with special flag or something?

-Werror by default would still be mildly annoying, but I'd like it a lot better than what Go and Zig do. At least then I could shell alias "go" to "go -Wno-error".

> So you don't publish it.

Why do they care?

> I guess they could have levels and allow them in debug mode or with special flag or something?

Well yes, that's how normal compilers do things.

I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers. Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier.

Of course if you’re the only developer working on your own codebase, you’d wonder why they care but you’re also not the main group they were targeting.

> I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers

So someone’s anal retentive was made into a langage mandate rather than anything actually useful?

> Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier.

Why are dead variables any dirtier than dead stores? Or unchecked errors?

> Why are dead variables any dirtier than dead stores?

If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this.

If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

In principle, a dead variable in final code is also almost certainly a mistake: either by not including the variable in the computation or for declaring the variable at all. Maybe a little annoying while you're figuring something out, but makes sense in the context of polished code.

> If you mean stores to fresh local variables

I mean stores for which there is no load.

> I assume that should also count in a proper/ideal implementation of this.

It certainly does in a proper implementation, but not in zig. Or go.

> If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

That sounds stupid.

> a dead variable in final code is also almost certainly a mistake

See “final code” is the issue at hand. The problem with go is that it specifically does not do that. It has a half-assed implementation which it forces upon you all the time.

> Maybe a little annoying while you're figuring something out

It’s a bloody nuisance when you new figuring things out or in the middle or refactoring something.

> but makes sense in the context of polished code.

There’s a ton more which makes sense “in the context of polished code” which go can’t be arsed to do.

Checking that errors are not implicitly ignored for starters.

> I mean stores for which there is no load.

Stores for which there are no load can still be observable in concurrent scenarios. That's why I specified stores to locals with no load because those are not observable.

> That sounds stupid.

Sounds totally reasonable to me in scenarios where you need the output of the compiler to be very predictable.

i could understand this in 1995, but in 2015? We have peer reviews, and CI. Let's deny warnings there, and allow them during development.

Use golangci-lint (https://golangci-lint.run, https://github.com/golangci/golangci-lint) which combines all of the best lints (including staticcheck).

This lint doesn't help with these situations, but other rules around values belonging to error unions would prevent you from porting this golang code to Zig.

Zig seems to behave similarly. This compiles:

  export fn x() i32 {
      var a: i32 = 1; // okay
      a = 2;
      return a;
  }

This does not:

  export fn x() i32 {
      var a: i32 = 1; // unused variable
      var a2: i32 = 2;
      return a2;
  }

> Not that this lint actually achieves that, or even prevents real errors.

I have to agree. If there's one thing I've learned over the years, it's that you can't prevent bad code by enforcing lint errors.

> If there's one thing I've learned over the years, it's that you can't prevent bad code by enforcing lint errors.

I completely disagree, I regularly catch mistakes/bugs in my own code due to enforced linting errors (both locally and in CI), and just in the past few months I can recall numerous instances where CI linting caught bugs in teammates' code too.

There are both false positives and false negatives with linting, but that doesn't make it useless at all.

And there are good and bad lints. If you want a somewhat view on what lints are good and bad go find some issues for Rust that discuss how to categorize a particular lint.

I don't think that's quite the same issue. That `a` is reassigned doesn't make it unused. It is, after all, a variable.

And that's why this issue is kind of hard. It's why I end up block scoping a lot of error code in Go, which is ugly but generally safer.

> I don't think that's quite the same issue.

It is.

> That `a` is reassigned doesn't make it unused. It is, after all, a variable.

But that's exactly why it's bad, "unused variable" is not a super useful signal in the first place, and if you assert that everything must be used then you need to protect against "unused stores" instead.

SSA tells us there is essentially no difference between assigning and reassigning.

> I have to agree. If there's one thing I've learned over the years, it's that you can't prevent bad code by enforcing lint errors.

A lot of simple cases can be handled with linting rules, BUT that, IMO requires a few additional things. Namely, being expression based, rather than statement based, and enforcing something like a hindley milner type system.

Zig will also let you return references to stack allocated objects.

is there no way to swap out lint "ignore" files for fucking around vs "I'm getting ready to test/release" rules ? That's what I do with c++ and python. I haven't only mucked around a bit with zig on godbolt though.

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.

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.

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.

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.

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

D literally has the switches `-release` and `-debug`.

It seems to me that a possible improvement would be for the compiler to error on unreachable code in `-release` and to warn in `-debug`.

Why don’t you fix those bugs?

-release is in there for magazine journalists who run benchmarks. -debug is for project managers to bring order to special debug code.

Doesn't D have a debugger? Hitting F9 then F5 sounds a lot faster than fiddling around with the code, hoping that you forget to remove the assert before you go home and that you won't spend time pleasing the compiler.

Yes, gdb. I don't particularly like gdb, though.

> hoping that you forget to remove the assert

I routinely add a lot of instrumentation when developing code. I use `git diff` to remove it before committing.

The compiler builds itself fast enough that this is not a problem. I have one window on the source, the other on the build.

In Virgil I usually do "var x = 1/0;", but there's a command-line option "-fatal-calls=<method glob>", so you can crash on a call to a specific set of methods and get a stacktrace.

Nearly everyone I speak to hates the unreachable error messages, by the way.

It's not useless to have them but they can be utterly infuriating for exactly the reason you mention since most projects have warnings-are-errors turned on.

The way I shut it up in a class is usually by branching on the this pointer. Sneaky.

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.

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

If I didn't use any programming language that I hated any part of, I wouldn't be able to write code.

What if the person you're replying to really, really likes Zig except for this one aspect of it?

Then they shouldn't get so mad at something that's merely annoying; it's bad for the heart and circulatory system.

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.

Is that why you ignored all the other responses to your comment?

So don't use Zig?

I see this comment a lot in response to feedback: "Don't like it? Don't use it!" Every single time, it reads to me as "stop complaining!" For as many times as I've seen the comment, I haven't been able to read it any other way.

Am I being uncharitable or is it really just a clear-cut attempt to silence debate?

Well it would depend on context. For a FOSS software in domain where there are tons of other options, it is much easier to use what one likes and ignore what one doesn't. So calling it silencing the debate sounds too strong when software in question is not some controlling the world type.

On the other hand in case cloud services like those provided Google/FB/Twitter/Cloudflare etc it is much more difficult to just go with "Don't use if you don't like" because not only there are not much alternative but also because sometimes Cloud service providers act in unison. So if one is pushed out from a service they are likely to be pushed from all other services too.

Yea, I was under the assumption there are literally thousands of programming languages and you can fork most of them when I replied.

I’m not usually a “just don’t use it” kind of guy, but in this case it’s valid, imo.

"Don't like it? Just fork it!" is a variant I see a lot in the FOSS world. It's equally pernicious in my view. Either you end up maintaining your own fork that nobody uses (and who wants to do that) or the fork is successful and half the community starts hating you for causing more fragmentation. Perhaps the most recent example of this I can think of is neovim, though in the language world python 2 vs 3 is so infamous that people have started hating the entire community from the outside.

All of this says to me that Zig is taking the wrong approach. Making highly controversial, opinionated features the standard with no way to opt out just leads to these endless debates. Languages (or any tools, for that matter) that stay out of the debate and just give everyone a flag tend to have much more welcoming communities.

I agree with a lot of this, in terms of the polarization and tribalism, which is often the result. Unfortunately, there is little that can be usually done, except use other programming languages (which are more agreeable) or fork/make your own.

Yeah, it's just really frustrating when a language like Zig comes along. It does so many things right and seems to have a really good philosophy. But then it includes some highly opinionated "features" that make it a non-starter for so many people who could otherwise benefit from it.

Because only get upset about this because they love zig

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

Setting aside the unused variables issue for a moment, you might want to take a moment to ponder the fact that not having warning messages is an explicit design choice, not a missing feature.

A dogmatic one, by the sounds of it.

Maybe this becomes the equivalent of `go fmt` in 10 years. “How I learned to stop worrying and love errors-only”

We've had -Werror forever, the consensus is it's a bad idea. In addition to everything else, you can't ever change the warnings, including fixing bugs in them, without potentially breaking code.

> We've had -Werror forever, the consensus is it's a bad idea.

Says who? Package repo maintainers? -Werror is actually quite divisive.

Anyone who wants to be able to compile a program with a different or newer compiler than the author last tested it on.

Well if one never stops to think about its potential merits, it can surely only be perceived as dogmatic. One thing is evaluating a choice in its full context and not liking it, another is demanding to have your vision be understood and accepted without being willing to grant the same courtesy first.

> you might want to take a moment to ponder the fact

> Well if one never stops to think about its potential merits

Listing some of those merits may be more productive than insisting people aren't thinking about it hard enough

I don't program in Zig, but I can think of a few reasons in principle:

1. WYSIWIG compiler: how many people have been complaining lately about C compilers eliminating code on them due to undefined behaviour? If you eliminate certain optimizations so your complier doesn't do this, like dead code/variable elimination, then what the code looks like is exactly what executes. This means some important optimizations may have to be done by hand. Eliminating dead variables could be one of them.

2. Arguably dead variables are a mistake. Either they're a (major) mistake because you neglected to include a value in your computation, or a (minor) mistake because you declared a superfluous variable that's never used.

3. If you want your code to be clear and as self-documenting as possible, unused variables are an impediment. I can't speak to the accuracy of Zig's analysis, but I can see how it would be annoying while working out an algorithm.

> another is demanding to have your vision be understood and accepted without being willing to grant the same courtesy first.

Is it available somewhere? I can't think anything why that compiler patch[0] can't be upstream (of course not default, but under a flag/different build mode/config option).

[0]: https://github.com/ziglang/zig/issues/335#issuecomment-10138...

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("")`.

IIRC there's already a Zig fork that turns that abomination off. I remember seeing it mentioned in that upstream issue OP mentioned.

Do you remember the name or have a link?

Maybe this: https://github.com/ziglang/zig/issues/335#issuecomment-10138...

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.

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

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.

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

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.

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

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

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.

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.

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

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

That was the first suggestion that Kelley posted on the issue and judging by the reactions people weren’t happy with it.

Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.

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

> 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

> 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 disagree, you are actively telling the compiler that this is dead code.

> I disagree, you are actively telling the compiler that this is dead code.

No, you would be doing that by removing the code. You are telling the compiler that this is code you want and to shut the fuck up.

This method is more a hack to confuse the compiler than a clean solution, and now this unused variable could stay in the code forever because the compiler won't ever mention it again.

Using `_ = var` to prevent the error is just as bad as handling Java exceptions with empty catch blocks.

His suggestion is even counterproductive in a way, because it makes it more likely people will accidentally commit unused vars they have silenced. I _want_ the compiler to help me find unused things... just not yet. Wait until my pre-commit hook to yell at me please!

I've definitely done this, and this is a good argument for changing the behavior.

That makes unused variables "used", which defeats the point of the check.

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.

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.

There's a nice eslint plugin for disable-line hygiene: https://www.npmjs.com/package/eslint-plugin-eslint-comments

I do wish Rust had something like this too

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.

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

Ah, yeah that would be cool. Sorry for misunderstanding!

This would be really cool! you should open up a RFC for it.

> Maybe it would be called #[expect(deprecated)]

Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek.

Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was even put forward back in July: https://github.com/rust-lang/rust/issues/54503#issuecomment-...

That's hilarious, I had no idea! I'm glad I didn't embarrass myself by proposing an RFC. Thanks for the links!

Thank you !

But then what if you accidentally check in that workaround?

The strict compiler check would have had exactly the opposite effect from the intended one.

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

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

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.

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

Thankfully the tabs thing is not meant to be permanent.

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.

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

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.

Reply on news.ycombinator.com