Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig 0.9.0

ziglang.org

Post reply on HN
Print view View original

21–30 of 250 posts

Re: Zig 0.9.0

#21

Post by db65edfc7996 »

jimbob45 wrote: post #15
db65edfc7996 wrote: post #14

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

If a local is intentionally unused, it can be discarded, like this: test "example" { var x: i32 = 1234; _ = x; } Do discards not fulfill your use case?

That is still more movement for when I am hacking out a feature. When I am trying to figure out an idea, I am liberally creating new variables and adding imports without care. In other languages, I can freely comment in/out large swaths of code as I understand the problem.

Not a deal-breaker (honestly, I write Python most days), but a huge annoyance.

Re: Zig 0.9.0

#22

Post by turminal »

flohofwoe wrote: post #12
vladharbuz wrote: post #3

I don't know if string handling has been improved, but it's one of the few things stopping me from using Zig. I look forward to 1.0, which will hopefully have proper strings. [0] [0]: https://github.com/ziglang/zig/issues/234

IMHO Zig's builtin string handling (or rather, lack of) is exactly right for a systems programming language. Zig avoids the biggest problem of C strings and treats strings as ptr/length slices, not as zero-terminated. UTF-8 for string literals is also fine. That's all that's needed (and should be implemented) on the language level, everything else should go into the standard library, and additional specialized string…

The issue with treating strings as slices/arrays is that it exposes (writably!) the underlying representation, which is almost never what you want and leads to subtle bugs.

The downside is of course the fact that you have to account for encodings in your language now, but picking the one and only sensible encoding really shouldn't be a problem in 2021.

Re: Zig 0.9.0

#23

Post by nauticacom »

db65edfc7996 wrote: post #14

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

Re: Zig 0.9.0

#24

Post by macintux »

nauticacom wrote: post #23
db65edfc7996 wrote: post #14

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

When you mistakenly used the wrong variable name instead, I suppose.

Re: Zig 0.9.0

#25

Post by diegocg »

flohofwoe wrote: post #12
vladharbuz wrote: post #3

I don't know if string handling has been improved, but it's one of the few things stopping me from using Zig. I look forward to 1.0, which will hopefully have proper strings. [0] [0]: https://github.com/ziglang/zig/issues/234

IMHO Zig's builtin string handling (or rather, lack of) is exactly right for a systems programming language. Zig avoids the biggest problem of C strings and treats strings as ptr/length slices, not as zero-terminated. UTF-8 for string literals is also fine. That's all that's needed (and should be implemented) on the language level, everything else should go into the standard library, and additional specialized string…

They can put it on the standard library or the core language or wherever they want, but they absolutely need to provide good string handling.

And regardless of where they put the code, this is something that needs to be done by the core team. Otherwise you will end with too many string libraries, all of them trying to solve a particular problem and doing bad at everything else, with bad documentation and different API styles and making difficult to mix code that uses two different libraries.

Re: Zig 0.9.0

#26

Post by AndyKelley »

flohofwoe wrote: post #16
db65edfc7996 wrote: post #14

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

One problem I see with this decision is that code will now be littered with: _ = bla; _ = blub; ...which have been forgotten during development. So the next thing that's needed is an error if 'bla' or 'blub' are actually used elsewhere ;)

Please note there is an accepted proposal[1] to add an unused keyword, making it possible to detect conflicts between things being marked unused and actually being used, and improving tooling integration.

[1]: https://github.com/ziglang/zig/issues/10245

Re: Zig 0.9.0

#27

Post by lijogdfljk »

nauticacom wrote: post #23
db65edfc7996 wrote: post #14

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

It happens. Hell, it even happens in Rust, i had one happen a few weeks ago that the warning lint caught. I had a rename and then added an inner scoped var of the old, previous name - but neglected to use that new var in that inner scope. Compiled fine, but was very much a bug.

Luckily though my Rust setup doesn't fail to compile with unused stuff, it just warns - and then on CI i have it reject all warnings.

I agree it's very frustrating not having a -dev flag or something less restrictive.

Re: Zig 0.9.0

#28

Post by dilap »

db65edfc7996 wrote: post #21
jimbob45 wrote: post #15

Earlier quoted context omitted.

If a local is intentionally unused, it can be discarded, like this: test "example" { var x: i32 = 1234; _ = x; } Do discards not fulfill your use case?

That is still more movement for when I am hacking out a feature. When I am trying to figure out an idea, I am liberally creating new variables and adding imports without care. In other languages, I can freely comment in/out large swaths of code as I understand the problem. Not a deal-breaker (honestly, I write Python most days), but a huge annoyance.

Yeah, it's a fair point. Per the zig writeup, the plan / hope for this use case is an editor command that will quickly add in all the "_ = unused" statements, which should take it down to very-small annoyance.

(From my use in Go, I'm definitely overall a fan of the feature. Tho of course how much personal value vs annoyance you get out of it is going to depend on your own code style and behaviors.)

Re: Zig 0.9.0

#29

Post by pcwalton »

nauticacom wrote: post #23
db65edfc7996 wrote: post #14

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

That warning has caught bugs for me when I was copy and pasting code, or writing code on "autopilot". Usually it's pretty obvious mistakes though.

Unused variable warnings are a good idea, but making them hard errors is a language design mistake. Warnings are good because they allow programmers to quickly make changes and test things, while providing a reminder to clean things up in the end (which is why the "just use tooling that removes unused variables" response misses the point--when making quick temporary changes for debugging, you want the warnings as reminders to go back and undo the change). Additionally, warnings allow for adding helpful static analyses to the compiler over time without breaking existing code like introducing new errors does. As I recall, there were some cases in which Rust 1.0 accidentally didn't flag unused variables, which was fixable post 1.0 without breaking existing code precisely because it was a warning, not an error.

Re: Zig 0.9.0

#30

Post by Vendan »

Zig is such a cool looking language, really just love the idea of comptime, but every time it comes up, all I can think about is how it's mandating spaces for indentations. I know it seems pedantic, but a programming language just saying "I don't care about accessibility by the visually impaired" when it is just text comes across as overbearing and insensitive.

https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...

Post reply on HN