Live data from Hacker News

Zig, the Small Language

zserge.com

61–70 of 429 posts

Re: Zig, the Small Language

#61
post #9

Earlier quoted context omitted.

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.

Re: Zig, the Small Language

#62

Earlier quoted context omitted.

Zig has good docs now? Nice. Last I looked Zig had some of the worst docs I'd seen to the point where I just looked at the std sources and eventually just gave up

Maybe language docs vs stdlib docs. Language docs are good for most topics, stdlib docs are much worse than stdlib sources.

That's exactly right. When I tried it, the Language Reference was great, and the stdlib documentation was a UX-challenged semi-broken webapp.

Re: Zig, the Small Language

#63
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…

I agree that array initialization syntax is weird a.f., but the other two points are very deliberate. I feel like you're implying they're legacy cruft.

Re: Zig, the Small Language

#64

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…

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

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.

Re: Zig, the Small Language

#65

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…

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

Re: Zig, the Small Language

#66
post #42

What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.

Language is the first layer; it should be as simple as possible.

Libraries then framework are the other layers, built on top of the language.

A language designer is unlikely to understand all the needs of the language users, trying to solve complex problems at the language level can seem neat and powerful for the exact use case it was intended, and also unnecessary/cumbersome/too general or not general enough for many more use cases.

Re: Zig, the Small Language

#68
post #42

What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.

Knee-jerk reaction to the internal Java that everyone has in their brain.

Re: Zig, the Small Language

#69
post #42

What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.

[deleted]

Re: Zig, the Small Language

#70
post #43

I don't know Zig, but aren't we missing a return here? fn count_nonzero(a: []const i32) i32 { var count: i32 = 0; for (items) |value| { // "for" works only on arrays and slices, use >"while" for generic loops. if (value == 0) { continue; } count += 1; // there is no increment operator, but there are shortcuts for +=, \*=, >>= etc. } }

That's correct.
Post reply on HN