6 ms·

For me Rust is a language that I would absolutely love to work with in a professional context. The type system and borrow checker have your back and help you ma

For me Rust is a language that I would absolutely love to work with in a professional context. The type system and borrow checker have your back and help you make changes to the code without fear of accidentally introducing any regressions. For private lone-hacking projects though it feels way too complex and opinionated. Here Zig definitely gets closer to what I need, though sadly it made unused variables an compiler error (curse you golang for making that popular) which is super annoying for prototyping.

vanderZwan 4y ago
I never understood this attitude, it's not like commenting out variables is difficult.
- simion314 4y ago
  >it's not like commenting out variables is difficult. But if you comment var A that uses var B now B is unused and you need to commnet B, but now B was using a function parameter C and this param is unused now so you need to update the function signature (I do not use Go,Zig so maybe they did not forced you to also use all the function params my experience is with linters where ehwn you comment something then more unused warnings appear)
  - vanderZwan 4y ago
    Wow sounds like you really need to clean up your codebase. Seriously, I have never had this problem while coding in Go, and I'm a very very sloppy coder.
    - spoiler 4y ago
      What are you talking about? I don't understand how you've never encountered variables depending on each other. In any moderately complex function you'll have more than one expression, and those can depend on each other. And you want them to be named and assigned; it makes it easier to read and decode intent and debug things (unless you're one of those wizards who get it right on the first try every time, kudos to you then). I'd not approve a PR that inlines/embeds complex concepts within larger expressions just to avoid creating variables... Edit: typos
      - vanderZwan 4y ago
        Of course I have encountered dependent variables, but if I have a long chain of unused variables that means that either that code is ready to go, or the code organization needs refactoring.
        hhmc 4y ago
        You seem to be missing the whole point being made — they are unused because of (temporary) changes during prototyping.
        vanderZwan 4y ago
        Ah yes, prototyping. The stage of coding where one has lots of snippets of code meant for trying things out quickly. Definitely a context full of long chains of dependent variables.
        hhmc 4y ago
        One might imagine prototyping new functionality in a existing, complex, codebase..
        afiori 4y ago
        At first you have a long chain of used variables that end up into a value used somewhere. If then you refactor away that single final value you need to delete all the previously used variables that now need to be "deallocated" by you.
        simion314 4y ago
        Dude, it is about debugging, or work in progress... Did you ever tried to debug some issue and start commenting stuff to try and find the problematic area? Hell when I comment stuff soemtimes private function will get unused , so with a shit compiler you would need to also comment the private functions, remove unused classes etc. In my code I assure the linter will say 0 warnings.
    - simion314 4y ago
      As other said, it is not a good practice so inline all the code, I prefer well named variables, and I assume you can find examples in your code where you have a local variable that depends of a function parameter. Funny enough I was correcting my son c++ homework yesterday, he had a complex if statement like if (somefunction(m,n, y[j]) == m[j]) and I made him make a local variable to make it clear what is happening. then the code was easier to understand and debug because we culd print that local variable and see if is fine. Btw, try not too respond that smug, you proved that you are an inexperienced coder and a shit person.
      - vanderZwan 4y ago
        I'm not so sure about that one, despite clearly being in the company of people who feel attacked, I'm not the one attacking people here. I'm commenting on code practices, and baffled at other people's rage about the compiler demanding that you don't have unused variables, but I haven't attacked anyone.
        simion314 4y ago
        You commented about my code quality, but I will assume you were in a rush and missunderstood that I was talking about work in progress stuff and debugging, so if that was teh case I apologize (if is not the case then you might understand in a few years)
    - xmonkee 4y ago
      I am seriously mind-blown that you've never encountered this problem in Go. You're trying something, and you see an error, you comment out a function and replace it with a print statement. And now suddenly you have to comment out a bunch of things up to the import statement just to fucking test out a simple hypothesis.
      - nindalf 4y ago
        Possibly because the IDE helps with that. Including adding and removing import statements. I feel like this complaint is more theoretical than something felt by people using Go day to day.
        simion314 4y ago
        People on the internet contradicts you, You remind me of the Apple fanboys and the keyboard issue , people complain that they keyboard has problems and the fanboys respond with "is working with me, you are using it wrong, you are stupid and probably eat at your keyboard, you broke it yourself" https://www.google.com/search?q=go+lang++compiler+warnings+unused+variables+!g&sourceid=chrome&ie=UTF-8 https://www.google.com/search?q=go+lang++compiler+warnings+u... All those people reporting the issue are not Go developers? Or maybe are not true Go developers, just the other kind, the ones that want generic and nice things. But yeah, I am not a Go dev, I used linters and I would hate having to be forced to clear all the unused warnings before I can test the code.
- oflor 4y ago
  It's not difficult, but it's disrupting to your coding flow, which is bad in itself and even worse when prototyping.
  - throwawaymaths 4y ago
    More disrupting than a really slow compiler?
    - adgjlsfhk1 4y ago
      allowing undefined variables doesn't slow down the compiler.
    - TakeBlaster16 4y ago
      Yes. If Zig takes 100ms to compile, and Rust takes 2s, but you just spent 20 seconds commenting unused vars in your Zig code, then the slow compiler comes out ahead. It's a great example of how good UX can be more important than raw performance numbers.
      - throwawaymaths 4y ago
        Yes, but you comment out unused variable once per variable (you can leave those underscores in and clear them out before release). The 2s happens every time you compile. The badness of slow compiles is non-linear, too. As you start to get to 30s, the likelihood that you check Facebook, Twitter, or hn goes up. At least when you're underscoring unused vars you're doing something active. If it gets to 2-5 minutes the likelihood that you stop writing tests and rely on the compiler for bugfreeness goes up - or the likelihood that you create debt by increasing the complexity of your code organization.
        TakeBlaster16 4y ago
        Strawman. Incremental compile times don't hit 2-5 minutes in either language, otherwise it obviously wouldn't be viable for real-world use. And juggling variables was an ongoing ordeal when I tried. I can't imagine how you would work on code without changing any of the variables.
- bluGill 4y ago
  It isn't difficult, but it is friction. You hit compile and a few seconds later you get an error that is unrelated to the change you wanted to test. I agree with all those errors once those changes are for production, but sometimes I wish the compiler would just shut up and let me test the actual change I just made to ensure it works. Commenting out a few variables isn't always easy either. Every try to add const to a legacy C++ project - it can take days to fix all the errors resulting from adding const to something that clearly is const in usage. I don't know zig, but I wouldn't be surprised if sometimes you get into this type of situation in a large code base (does anyone have a very large code base in zig yet?)
  - vanderZwan 4y ago
    > It isn't difficult, but it is friction. Only until getting rid of unused variables becomes a habit before you hit the compiler. Which is a good habit to have anyway.
    - rcxdude 4y ago
      it's still friction when it's a habit, there's a cognitive overhead to tracking that every time you make a change.
    - hota_mazi 4y ago
      Good habit, maybe, but it shouldn't cause a compilation failure. Add to that the snowball effect: you comment out a variable, compile, and you get another error because commenting out variable a made variable b unused. Rinse and repeat. It's a huge and totally unnecessary time sink. It should be opt-in, so that it's a warning by default, and then, when I'm ready to push my code, I could run some --strict mode that would force me to clean up my code.
      - NyxWulf 4y ago
        One of the features in go that makes it workable is you can assign it away via: _ = somevar That eliminates the unused chain problem. Not sure if zig included that part of the feature as well. Generally I agree though. The main problem with forcing unused variables, imo, is that it forces you to think a certain way. When I'm exploring the solution space on something, those constraints feel inhibiting.
- anothernewdude 4y ago
  I just want the quick edit to test something to be quick.
- bsder 4y ago
  It is when you have chains of them: see Vulkan setup. In Zig, I find that I put a whole litany of "_ = varname;" at the bottom of my functions (starting with the function arguments) and they stay there permanently. This is NOT an improvement. However, it's not really enough to stop me from using the language as that's an easy thing to evantually fix.
rcxdude 4y ago
It is a truly bizarre decision for a language which aims to have a fast change->compile->run cycle, since it can basically double the time the compile cycle takes.
- xedrac 4y ago
  Yeah, I would like a flag that makes the compiler as loose as possible, maybe something like "-fprototype". Then when I'm ready to get serious about correctness, I can remove the flag and be all pedantic.
TakeBlaster16 4y ago
That's the one thing keeping me from considering Zig for new projects right now. If some enterprising young developer is reading this and wants to make a name for themselves, you should fork the Zig compiler and change those errors to warnings. It would be an extremely popular project. EDIT: I'll even give you a catchy project name. Wig: Zig with Warnings
- nicoburns 4y ago
  There's actually already a patch for this posted on the github issue. It's only about a 5 line change.
  - TakeBlaster16 4y ago
    The patch works, but it's not efficient to have every user patch their own compiler on every release (and forgo the system package manager for upgrades). I was also envisioning adding a warning system, changing the checks to warnings instead of removing them completely, and adding a `-Werror` flag (or maybe `-Wno-error`). It would be a bit more than 5 lines, but still relatively low effort compared to how impactful the project would be.
    - fuu_dev 4y ago
      It might be good to add a respectful comment on the issue on github to emphasize the UX issues it creates. issue: https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/335
- refulgentis 4y ago
  You should also consider that optimizing for incorrectness and prototyping speed might not be the professionally responsible choice in 2022.
  - alpaca128 4y ago
    Unused variables don't make a program incorrect. When you comment out unused variables to prevent Zig's compiler error you don't remove the dead code, you in fact make it more likely to stay in the codebase because now it's only visible to humans. While almost every other language will print out a clearly visible warning without disrupting the workflow. I can only see downsides and no upside in this design. Why would you slow down the development workflow for something any decent compiler will discard as basic optimization step? It's an error about something that has absolutely no impact on the resulting program and its execution, you can probably find a dozen better reasons for Zig to throw errors where it doesn't.
kristoff_it 4y ago
The current plan is for `zig fmt` to have an optional flag that makes it automatically fix unused variables.
- TakeBlaster16 4y ago
  That's just going to result in people committing unused vars to their repos. People are already doing that now after adding '_'s by hand. https://news.ycombinator.com/item?id=32753079 https://news.ycombinator.com/item?id=32753079 It's going to get even more common when underscores are automatically added all over your project without user input and you have no chance of remembering where they all were. If the goal of not having warnings is to increase code quality, it's actually doing the opposite. I don't understand this insistence on working around the problem by layering on tooling, instead of just fixing the problem to begin with.

vanderZwan 4y ago

I never understood this attitude, it's not like commenting out variables is difficult.

simion314 4y ago
>it's not like commenting out variables is difficult. But if you comment var A that uses var B now B is unused and you need to commnet B, but now B was using a function parameter C and this param is unused now so you need to update the function signature (I do not use Go,Zig so maybe they did not forced you to also use all the function params my experience is with linters where ehwn you comment something then more unused warnings appear)
- vanderZwan 4y ago
  Wow sounds like you really need to clean up your codebase. Seriously, I have never had this problem while coding in Go, and I'm a very very sloppy coder.
  - spoiler 4y ago
    What are you talking about? I don't understand how you've never encountered variables depending on each other. In any moderately complex function you'll have more than one expression, and those can depend on each other. And you want them to be named and assigned; it makes it easier to read and decode intent and debug things (unless you're one of those wizards who get it right on the first try every time, kudos to you then). I'd not approve a PR that inlines/embeds complex concepts within larger expressions just to avoid creating variables... Edit: typos
    - vanderZwan 4y ago
      Of course I have encountered dependent variables, but if I have a long chain of unused variables that means that either that code is ready to go, or the code organization needs refactoring.
      - hhmc 4y ago
        You seem to be missing the whole point being made — they are unused because of (temporary) changes during prototyping.
        vanderZwan 4y ago
        Ah yes, prototyping. The stage of coding where one has lots of snippets of code meant for trying things out quickly. Definitely a context full of long chains of dependent variables.
        hhmc 4y ago
        One might imagine prototyping new functionality in a existing, complex, codebase..
      - afiori 4y ago
        At first you have a long chain of used variables that end up into a value used somewhere. If then you refactor away that single final value you need to delete all the previously used variables that now need to be "deallocated" by you.
      - simion314 4y ago
        Dude, it is about debugging, or work in progress... Did you ever tried to debug some issue and start commenting stuff to try and find the problematic area? Hell when I comment stuff soemtimes private function will get unused , so with a shit compiler you would need to also comment the private functions, remove unused classes etc. In my code I assure the linter will say 0 warnings.
  - simion314 4y ago
    As other said, it is not a good practice so inline all the code, I prefer well named variables, and I assume you can find examples in your code where you have a local variable that depends of a function parameter. Funny enough I was correcting my son c++ homework yesterday, he had a complex if statement like if (somefunction(m,n, y[j]) == m[j]) and I made him make a local variable to make it clear what is happening. then the code was easier to understand and debug because we culd print that local variable and see if is fine. Btw, try not too respond that smug, you proved that you are an inexperienced coder and a shit person.
    - vanderZwan 4y ago
      I'm not so sure about that one, despite clearly being in the company of people who feel attacked, I'm not the one attacking people here. I'm commenting on code practices, and baffled at other people's rage about the compiler demanding that you don't have unused variables, but I haven't attacked anyone.
      - simion314 4y ago
        You commented about my code quality, but I will assume you were in a rush and missunderstood that I was talking about work in progress stuff and debugging, so if that was teh case I apologize (if is not the case then you might understand in a few years)
  - xmonkee 4y ago
    I am seriously mind-blown that you've never encountered this problem in Go. You're trying something, and you see an error, you comment out a function and replace it with a print statement. And now suddenly you have to comment out a bunch of things up to the import statement just to fucking test out a simple hypothesis.
    - nindalf 4y ago
      Possibly because the IDE helps with that. Including adding and removing import statements. I feel like this complaint is more theoretical than something felt by people using Go day to day.
      - simion314 4y ago
        People on the internet contradicts you, You remind me of the Apple fanboys and the keyboard issue , people complain that they keyboard has problems and the fanboys respond with "is working with me, you are using it wrong, you are stupid and probably eat at your keyboard, you broke it yourself" https://www.google.com/search?q=go+lang++compiler+warnings+unused+variables+!g&sourceid=chrome&ie=UTF-8 https://www.google.com/search?q=go+lang++compiler+warnings+u... All those people reporting the issue are not Go developers? Or maybe are not true Go developers, just the other kind, the ones that want generic and nice things. But yeah, I am not a Go dev, I used linters and I would hate having to be forced to clear all the unused warnings before I can test the code.
oflor 4y ago
It's not difficult, but it's disrupting to your coding flow, which is bad in itself and even worse when prototyping.
- throwawaymaths 4y ago
  More disrupting than a really slow compiler?
  - adgjlsfhk1 4y ago
    allowing undefined variables doesn't slow down the compiler.
  - TakeBlaster16 4y ago
    Yes. If Zig takes 100ms to compile, and Rust takes 2s, but you just spent 20 seconds commenting unused vars in your Zig code, then the slow compiler comes out ahead. It's a great example of how good UX can be more important than raw performance numbers.
    - throwawaymaths 4y ago
      Yes, but you comment out unused variable once per variable (you can leave those underscores in and clear them out before release). The 2s happens every time you compile. The badness of slow compiles is non-linear, too. As you start to get to 30s, the likelihood that you check Facebook, Twitter, or hn goes up. At least when you're underscoring unused vars you're doing something active. If it gets to 2-5 minutes the likelihood that you stop writing tests and rely on the compiler for bugfreeness goes up - or the likelihood that you create debt by increasing the complexity of your code organization.
      - TakeBlaster16 4y ago
        Strawman. Incremental compile times don't hit 2-5 minutes in either language, otherwise it obviously wouldn't be viable for real-world use. And juggling variables was an ongoing ordeal when I tried. I can't imagine how you would work on code without changing any of the variables.
bluGill 4y ago
It isn't difficult, but it is friction. You hit compile and a few seconds later you get an error that is unrelated to the change you wanted to test. I agree with all those errors once those changes are for production, but sometimes I wish the compiler would just shut up and let me test the actual change I just made to ensure it works. Commenting out a few variables isn't always easy either. Every try to add const to a legacy C++ project - it can take days to fix all the errors resulting from adding const to something that clearly is const in usage. I don't know zig, but I wouldn't be surprised if sometimes you get into this type of situation in a large code base (does anyone have a very large code base in zig yet?)
- vanderZwan 4y ago
  > It isn't difficult, but it is friction. Only until getting rid of unused variables becomes a habit before you hit the compiler. Which is a good habit to have anyway.
  - rcxdude 4y ago
    it's still friction when it's a habit, there's a cognitive overhead to tracking that every time you make a change.
  - hota_mazi 4y ago
    Good habit, maybe, but it shouldn't cause a compilation failure. Add to that the snowball effect: you comment out a variable, compile, and you get another error because commenting out variable a made variable b unused. Rinse and repeat. It's a huge and totally unnecessary time sink. It should be opt-in, so that it's a warning by default, and then, when I'm ready to push my code, I could run some --strict mode that would force me to clean up my code.
    - NyxWulf 4y ago
      One of the features in go that makes it workable is you can assign it away via: _ = somevar That eliminates the unused chain problem. Not sure if zig included that part of the feature as well. Generally I agree though. The main problem with forcing unused variables, imo, is that it forces you to think a certain way. When I'm exploring the solution space on something, those constraints feel inhibiting.
anothernewdude 4y ago
I just want the quick edit to test something to be quick.
bsder 4y ago
It is when you have chains of them: see Vulkan setup. In Zig, I find that I put a whole litany of "_ = varname;" at the bottom of my functions (starting with the function arguments) and they stay there permanently. This is NOT an improvement. However, it's not really enough to stop me from using the language as that's an easy thing to evantually fix.

rcxdude 4y ago

It is a truly bizarre decision for a language which aims to have a fast change->compile->run cycle, since it can basically double the time the compile cycle takes.

xedrac 4y ago
Yeah, I would like a flag that makes the compiler as loose as possible, maybe something like "-fprototype". Then when I'm ready to get serious about correctness, I can remove the flag and be all pedantic.

TakeBlaster16 4y ago

That's the one thing keeping me from considering Zig for new projects right now. If some enterprising young developer is reading this and wants to make a name for themselves, you should fork the Zig compiler and change those errors to warnings. It would be an extremely popular project. EDIT: I'll even give you a catchy project name. Wig: Zig with Warnings

nicoburns 4y ago
There's actually already a patch for this posted on the github issue. It's only about a 5 line change.
- TakeBlaster16 4y ago
  The patch works, but it's not efficient to have every user patch their own compiler on every release (and forgo the system package manager for upgrades). I was also envisioning adding a warning system, changing the checks to warnings instead of removing them completely, and adding a `-Werror` flag (or maybe `-Wno-error`). It would be a bit more than 5 lines, but still relatively low effort compared to how impactful the project would be.
  - fuu_dev 4y ago
    It might be good to add a respectful comment on the issue on github to emphasize the UX issues it creates. issue: https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/335
refulgentis 4y ago
You should also consider that optimizing for incorrectness and prototyping speed might not be the professionally responsible choice in 2022.
- alpaca128 4y ago
  Unused variables don't make a program incorrect. When you comment out unused variables to prevent Zig's compiler error you don't remove the dead code, you in fact make it more likely to stay in the codebase because now it's only visible to humans. While almost every other language will print out a clearly visible warning without disrupting the workflow. I can only see downsides and no upside in this design. Why would you slow down the development workflow for something any decent compiler will discard as basic optimization step? It's an error about something that has absolutely no impact on the resulting program and its execution, you can probably find a dozen better reasons for Zig to throw errors where it doesn't.

kristoff_it 4y ago

The current plan is for `zig fmt` to have an optional flag that makes it automatically fix unused variables.

TakeBlaster16 4y ago
That's just going to result in people committing unused vars to their repos. People are already doing that now after adding '_'s by hand. https://news.ycombinator.com/item?id=32753079 https://news.ycombinator.com/item?id=32753079 It's going to get even more common when underscores are automatically added all over your project without user input and you have no chance of remembering where they all were. If the goal of not having warnings is to increase code quality, it's actually doing the opposite. I don't understand this insistence on working around the problem by layering on tooling, instead of just fixing the problem to begin with.