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

221–230 of 429 posts

Re: Zig, the Small Language

#221

Post by kristoff_it »

lopatin wrote: post #195
kristoff_it wrote: post #169

Earlier quoted context omitted.

> 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. Setting aside the unused variables issue for a moment, you might want to take a moment to ponder the fact that not having warning messages is an explicit design choice, not a missing feature.

A dogmatic one, by the sounds of it.

Well if one never stops to think about its potential merits, it can surely only be perceived as dogmatic. One thing is evaluating a choice in its full context and not liking it, another is demanding to have your vision be understood and accepted without being willing to grant the same courtesy first.

Re: Zig, the Small Language

#222

Post by pcwalton »

kristoff_it wrote: post #213
pcwalton wrote: post #174

Earlier quoted context omitted.

> Zig has full spatial memory safety, which is already a huge improvement over C. I don't believe this is true. Zig has pointers to unknown numbers of items, which don't seem bounds checked: https://ziglang.org/documentation/master/#Pointers They prefer slices idiomatically, but that's not "full spatial memory safety". C also prefers you to pass the length of every array whenever you pass a pointer to it, in that cor…

> You might be able to say something like "Zig minus features X, Y, and Z has full spatial memory safety". I'd be interested to see what features those are: it looks like at a minimum you would have to get rid of multi-element pointers and extern unions. Well, `[*]` pointers and extern unions exist for C interoperability. I'm sure that Rust has to do something comparable when interfacing with C. These pointers actual…

I didn't say that multi-element pointers were a bad feature, simply that they're a counterexample to the claim that Zig has spatial memory safety.

Generally in memory-safe languages the corresponding features are behind some kind of "unsafe" marker: in Rust and C# they're behind "unsafe", in Java they're behind "sun.misc.Unsafe", etc. I don't see any such marker in Zig.

Re: Zig, the Small Language

#223

Post by delijati »

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…

Yeah i run into the same issue, but the worst part of it, it wasn't my code i added a library and the compiler complaint unreachable code there oO

Re: Zig, the Small Language

#224

Post by flumpcakes »

masklinn wrote: post #219
flumpcakes wrote: post #189

Earlier quoted context omitted.

It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable. Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising. If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. I think we do all a…

> It is not useless though. True, it's actively harmful. > There is a big difference between an unused variable and explicitly defining an unused variable. Which is not helpful when you're only doing it to hide a compiler error foisted upon you. > Kelly is designing Zig to do nothing surprising or change things underneath you. Refusing to compile my code because I've an unused variable is certainly surprising. > If y…

> That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising.

I disagree, you are actively telling the compiler that this is dead code.

Re: Zig, the Small Language

#225

Post by masklinn »

Symmetry wrote: post #192
WalterBright wrote: post #53

Earlier quoted context omitted.

Here's a sweet example of proper use of operator overloading: https://dlang.org/phobos/std_checkedint.html where operator overloading is used to create variations on integer types, like specifying the behavior when overflow happens. Besides, `a + b / (c * d)` is far more readable than `add(a, div(b, mul(c, d)));

I think haskell does this right. You can make function infix by turning "add a b" into "a `add` b" and you can't overload existing operators but you can make your own and do "a _+ b" or whatever and everybody will know it isn't the standard + but it's still readable.

> you can't overload existing operators

You can though, just implement the relevant typeclass.

Not only that, but you can straight up shadow existing operators.

Re: Zig, the Small Language

#226

Post by mirekrusin »

adamddev1 wrote: post #104
VyseofArcadia wrote: post #85

Earlier quoted context omitted.

> 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. In my experience, languages with complex features still have complex libraries. Library complexity is a constant. If you simplify the language, at least you free up a little cognitive load there. In addition, simplifying t…

Like Smalltalk/Pharo, you have 6 keywords in the language and the syntax fits on a postcard. But all the classes/library/environment is huge and complex.

Binary is very simple you need to memorize 0 and 1 and that's it, screw Newton from one of comments above, right?

Re: Zig, the Small Language

#227

Post by mirekrusin »

chriswarbo wrote: post #111
jayd16 wrote: 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.

Going from N features to N+1 features creates N! new interactions to consider. For example, if we have a bunch of language features, and we decide to add a new one, e.g. exceptions, we now have to consider: - How exceptions work - How exceptions interact with threads; how exceptions interact with dynamic binding; how exceptions interact with dynamic binding in threads; how exceptions interact with mutable variables;…

That's why algebraic effects are cool, right?

Re: Zig, the Small Language

#228

Post by mirekrusin »

ironmagma wrote: post #71
jayd16 wrote: 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.

The most perfect code is no code at all. A language being small means it unlocks power without complexity. Smalltalk is a great example of this as it was rewritten over and over until it was tiny. Of course, "no code at all" isn't useful, so there's a medium to be found.

Unlocking power without complexity is not implied by being small. Logo doesn't unlock power by allowing you to move turtle and binary encoding doesn't make things easier by allowing you to write 0 or 1 only.

Re: Zig, the Small Language

#229

Post by p0nce »

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…

That's a reason why D's default are permissive. You add this or that constraints later, as needed.

Re: Zig, the Small Language

#230

Post by [deleted] »

Symmetry wrote: post #192
WalterBright wrote: post #53

Earlier quoted context omitted.

Here's a sweet example of proper use of operator overloading: https://dlang.org/phobos/std_checkedint.html where operator overloading is used to create variations on integer types, like specifying the behavior when overflow happens. Besides, `a + b / (c * d)` is far more readable than `add(a, div(b, mul(c, d)));

I think haskell does this right. You can make function infix by turning "add a b" into "a `add` b" and you can't overload existing operators but you can make your own and do "a _+ b" or whatever and everybody will know it isn't the standard + but it's still readable.

[deleted]
Post reply on HN