Hacker News Reader

Comment by rcarmo | Hacker News Reader

26 or so data points, but still interesting. I myself have become enamored with Zig's relative simplcity and straightforwardness, although some of my friends keep telling me to do Rust instead.

View on HN

Yeah, not a lot of data points, and a niche subject, game dev, but I am playing with the Mach game and graphics engine, and so far so good. I started programming in 1978 in CPM Basic, C, 6502 assembler, etc. I play with Rust, but if I am really looking for high-integrity software, I am currently using SPARK2014 (the subset of Ada), that has some legs beneath it. Rust and AdaCore are starting to work together to bring some of this into Rust, but it's not there yet. So for me, Zig is my C replacement, and SPARK2014 is my C++/Rust replacement. You can go low-level with SPARK2014 too, and IMHO, it is far easier to understand than Rust, yet it already has all the high concepts of software integrity, safety, and verifiability. Excited about cross-platform graphics and performance with Zig and Mach.

Thanks for sharing. Going to enjoy some time with Spark2014.

OT: Searching for Spark2014 brings up a lot of results about the 2014 Chevrolet Spark. A shit box of a car of there ever was one.

Hah, Chevy Spark, and it's a gasoline car!

I usually put "SPARK2014 programming" or "SPARK2014 Ada" in my searches. I used to get annoyed by all of the Apache Spark stuff that came up, but that seems to have waned a bit this past year or two.

Vermont Technical College (VTC) used SPARK2014 to program their CubeSat and the book, "Building High Integrity Applications with SPARK"[1] is a great intro to it in a nice context of practical use.

There was also an article on the AdaCore site about someone who rewrote some drone firmware in SPARK2014, which is another nice real-world application. [2]

[1] https://www.amazon.com/Building-High-Integrity-Applications-...

[2] https://blog.adacore.com/how-to-prevent-drone-crashes-using-...

Gasoline cars have sparkplugs, so it's not really a strange association. At least not in my opinion.

In fact, I guess in gas cars sparks are "better" since they are engineered in, and doing useful work.

I didn't say it was strange. I found it amusing that this is what came up during the other person's search for SPARK2014, and yes, thinking it sounded like a suitable electric vehicle name. Chevy called their electric offering Volt, and Volts are in the battery in a gas car too, but I think you get the picture.

How is Spark2014 easier to understand than Rust? The borrowing rules [1] are more or less the same.

[1]: https://docs.adacore.com/spark2014-docs/html/ug/en/source/la...

Perhaps "understand" was the wrong word given I meant for me to understand. I have a C background and Pascal as well as assembler back in the day (late 70s/early 80s). I dove into Ada/SPARK2014 and picked it up much quicker than Rust. Ada has been around a lot longer than Rust, so I think it's syntax allows for a clearer readability even if they have similar borrowing rules. If I had my druthers I'd be programming in APL or J all the time, so take what I find clearer with a grain of salt. There wasn't as much tribalism around PLs as there is nowadays. I guess people stake a lot of emotion on what they have chosen as their main language or programming paradigm they may have committed so much of their time learning. I still recommend Ada/SPARK2014 to anyone who asks me about verifiable or high-inegrity software with a follow on comment to keep an eye on Rust especially with Adacore and Ferrous Systems teaming up to help Rust get there. Zig does not have a major sponsor like Rust, but it appeals to the low-level hacker, former C programmer. I love playing with Hexops' Mach game engine and graphics toolkit in Zig! I tried Bevy and Rust, but it just doesn't flow as quickly for me. Maybe it does for others.

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.

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

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

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.

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

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.

You seem to be missing the whole point being made — they are unused because of (temporary) changes during prototyping.

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.

One might imagine prototyping new functionality in a existing, complex, codebase..

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.

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.

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.

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.

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)

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.

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.

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

It's not difficult, but it's disrupting to your coding flow, which is bad in itself and even worse when prototyping.

More disrupting than a really slow compiler?

allowing undefined variables doesn't slow down the compiler.

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.

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.

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.

It's really not a problem for me. I've worked on probably about 20k LOC of zig. Probably the one time it was an issue was when I wrote some code that wrote zig -- and then it pushed me into realizing that this was a code smell, and a refactoring fixed it.

Compile times of 2-5 minutes can happen in langs that are not rust. You mentioned rust, not me. And anyways the 30s to hn thing is real.

> (you can leave those underscores in and clear them out before release)

You can leave those "unused variable" warnings and fix them before release

The difference is that warnings are visible, the underscores however suppressed the compiler's ability to help you.

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

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

it's still friction when it's a habit, there's a cognitive overhead to tracking that every time you make a change.

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.

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.

> you can assign it away via: _ = somevar

If one suggested this in any other language to suppress "unused variable" warnings it would be considered a lazy way to avoid fixing the issue.

Meanwhile the developer of Zig himself recommended doing this[0] which only shows what a bad idea it is to make this a compiler error imho. It encourages workarounds and enforces something we automated long ago in the form of dead code elimination.

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

It's how Go works...

I just want the quick edit to test something to be quick.

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.

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.

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.

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

There's actually already a patch for this posted on the github issue. It's only about a 5 line change.

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.

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

You should also consider that optimizing for incorrectness and prototyping speed might not be the professionally responsible choice in 2022.

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.

"Optimizing for incorrectness" is a funny way to describe the practice of enforcing lint checks as part of a CI pipeline.

You're right, the provocation here is engaging in intentionally choosing a language, and choosing Zig, is optimizing for incorrectness. I didn't mean the flag.

I also misinterpreted the comment. Either way, I don't see the harm in optimizing for prototyping speed. It's orthogonal to the safety issues.

You're not alone.

Fridays are my live streaming day and I've chosen today's topic to be the user experience of unused variable errors. I have an idea to solve this that can satisfy both parties - those who don't want to be bothered by such errors, and those who want the premise upheld that if Zig code compiles, it does not have any unused variables.

In approximately 60 minutes I'll go live on https://www.twitch.tv/andrewrok/

Nice to see you here. I'm not much of a twitch guy, but I'm glad this is on your radar and I'll read about it afterwards!

If you're talking about the `zig fmt` idea, I'd like to draw your attention to a possible pitfall -- Silencing the errors with _ increases the risk that unused vars will be committed to the repo. https://news.ycombinator.com/item?id=32753079

I normally add the equivalent of `-Werror` to pre-commit and CI. But if those warnings are silenced directly in the source code, I can no longer rely on the compiler's guidance to clean up the code, and I would have to hope I could remember all the places I need to clean up before committing. In that way, solving this in the formatter could have the opposite effect on code quality than you intended. I _do_ want the compiler to yell at me... just not yet. Only when it comes time to commit.

Overall I've been impressed reading about Zig's design. You clearly have good engineering taste and I respect you challenging the status quo and trying unconventional ideas, even if I may disagree from time to time. I'm itching to start using the language once this is solved!

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

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

Reply on news.ycombinator.com