Live data from Hacker News

Zig, the Small Language

zserge.com

51–60 of 429 posts

Re: Zig, the Small Language

#51
IME, general purpose "small" languages rarely stay small.

Even C has accreted a lot of features.

I think Python was small at some point.

Pascal was small at some point, but by Delphi had become quite big.

Go has just added generics.

I think looking at a "smallness" for a relatively young language is likely to be misleading.

Re: Zig, the Small Language

#53

Earlier quoted context omitted.

if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity

> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately. operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.

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

Re: Zig, the Small Language

#54
post #16

why do people care about binary size? I have never understood this. Disk space isn't free but the size of the binaries on my machine doesn't seem like a big problem to me in that regard.

In practice, binary size does not matter much for most use cases. (But for embedded and demo scene this is important)

It is a simple proxy/heuristic for the level of bloat / crust / overengineering of the runtime and to the quality of the compiler.

If a language / framework can't do an extremely simple task in an almost optimal fashion, then it is unlikely that it will improve with more difficult tasks.

It is like looking at the CPU/GPU load of an app in idle mode.

Re: Zig, the Small Language

#55

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("")`.

Re: Zig, the Small Language

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

As the total number of ways to accomplish a task increases it puts more burden on a programmer to recognize the usage and understand the semantic differences between the options. How many ways are there to iterate over a collection in say C++?

Libraries _can_ hide some of this, but then that might also be yet another function or operator that does the same thing. Internalizing when to use one method vs. another adds to the total cognitive load of using the language, and it takes away from the mental capacity available for the problem you are actually trying to solve.

Sometimes these differences are necessary and important, other times they are less so.

Re: Zig, the Small Language

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

simpler languages are easier to learn and to remember. small languages make software easier to write and to read.

complex features (in a language that does the simple things correctly) are always easily composed from the simple features available.

the antithesis of small languages is C++, which is probably the most popular language on the planet in which 0% of its users know 100% of.

with a small language, i can’t use language features which you do not understand when it comes to read my code or take over maintenance, or even understand it.

Re: Zig, the Small Language

#58

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…

Have you considered adding a dedicated `breakpoint` keyword for this use case? Linters could ignore it, but the compiler could warn or error. The problem with workarounds like `assert(0)` is that the linter lacks context to do the right thing.

Re: Zig, the Small Language

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

A lot of complexity is unnecessary, that is what zig tries to avoid

Zig is still pretty feature rich (for instance, full generics support) but remains small and simple

Re: Zig, the Small Language

#60

IME, general purpose "small" languages rarely stay small. Even C has accreted a lot of features. I think Python was small at some point. Pascal was small at some point, but by Delphi had become quite big. Go has just added generics. I think looking at a "smallness" for a relatively young language is likely to be misleading.

I mean, zig manages full generics while still being simple
Post reply on HN