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

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

131–140 of 429 posts

Re: Zig, the Small Language

#131

Post by properparity »

wyldfire wrote: post #14
Kukumber wrote: post #7

Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a…

"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.

How is w=add(u, v) more explicit than w=u+v?

Because operators "should not be function calls"?

That would make zig unusable on soft float/soft div architectures, or would have to get rid of / for division and operators for floats.

But I would also assume add() is inlined and not be a function call in a sane language/compiler, so the explicitness even falls apart from the start.

Re: Zig, the Small Language

#132

Post by TakeBlaster16 »

steveklabnik wrote: post #118
TakeBlaster16 wrote: post #86

Earlier quoted context omitted.

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

Re: Zig, the Small Language

#133

Post by flohofwoe »

cercatrova wrote: post #100
ok123456 wrote: post #92

Earlier quoted context omitted.

Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also direct…

But the problems still remain? The borrow checker is an automated way of what one would normally check by hand, or in their mind. Removing it means that, just as one does in C, one must still check for memory errors and will more likely miss such errors more than the borrow checker does.

Zig isn't "watertight" like Rust, but the memory safety is still much closer to Rust than to C or C++, just because Zig enforces a lot more correctness in the language, and because of runtime checks. And a lot of memory corruption issues in C and C++ are actually side effects of C's and C++'s fairly relaxed approach to things like integer conversions, over/underflow, range checking etc... these are all points that Zig covers (for some of those things even when compiling C/C++ code because of the much stricter default compile options than regular C/C++ compilers).

(disclaimer: Zig has or had some pretty big holes around escape-checking function return values - that's something that even C compiler are warning about these days, at least for simple cases - but apparently improving this aspect is on the todo list).

Re: Zig, the Small Language

#134

Post by sl3dge78 »

Graziano_M wrote: post #95
ptato wrote: post #74

Earlier quoted context omitted.

It's really 4. It doesn't count the sentinel, just the elements. `@sizeOf([4:0]u8)` is 5 though.

Oh, that's strange. So you can actually read (just 1) past len?

Yeah, it's made to feel like strlen in a way. Sentinel types are mostly used with C code. That way strlen(some_string) == some_string.len.

Re: Zig, the Small Language

#135

Post by steveklabnik »

TakeBlaster16 wrote: post #132
steveklabnik wrote: post #118

Earlier quoted context omitted.

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!

Re: Zig, the Small Language

#136

Post by cle »

TakeBlaster16 wrote: post #65
masklinn wrote: post #22

Earlier quoted context omitted.

> 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, b…

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.

Re: Zig, the Small Language

#137

Post by sph »

TakeBlaster16 wrote: post #4

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…

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.

Re: Zig, the Small Language

#138

Post by mirekrusin »

masklinn wrote: post #88
llimllib wrote: post #36

Earlier quoted context omitted.

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…

> 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`…

So you don't publish it.

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

Re: Zig, the Small Language

#139

Post by sph »

ptato wrote: post #55
TakeBlaster16 wrote: post #4

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…

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.

Re: Zig, the Small Language

#140

Post by oconnor663 »

WalterBright wrote: post #37
TakeBlaster16 wrote: post #4

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…

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…

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

Post reply on HN