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

81–90 of 429 posts

Re: Zig, the Small Language

#81

Post by verdagon »

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.

For many situations, a language will add a lot of complexity that doesn't bring much benefit. In the end, a language's complexity can sometimes be a net detriment to its user.

For example, one might be making an embedded program where all memory is pre-allocated up-front and there's no heap usage. There's not as many opportunities to mess that up than your average program. This is where Zig would shine compared to e.g. Rust whose borrow checker would be helping with less, yet is imposing its usual complexity burden on the programmer.

Re: Zig, the Small Language

#82

Post by ptato »

synergy20 wrote: post #76

is zig still one man's work and has a hit-by-a-bus risk factor? checked it a few weeks ago for a few hours, looks good, but I don't feel I need switch from c to zig yet. will re-try after 1.0 is out.

The "People" section on the right on their github organization[0] shows members of the core team. It's also free software and surrounded by a passionate community, so it's pretty hard that it would die out. Andrew is irreplaceable though.

[0] https://github.com/ziglang

Re: Zig, the Small Language

#84

Post by nobleach »

synergy20 wrote: post #76

is zig still one man's work and has a hit-by-a-bus risk factor? checked it a few weeks ago for a few hours, looks good, but I don't feel I need switch from c to zig yet. will re-try after 1.0 is out.

the scarier prospect right now is that if you DO wait for 1.0, it'll likely have a very different API.

Re: Zig, the Small Language

#85

Post by VyseofArcadia »

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.

> 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 the language often implies (or is even equivalent to) minimizing footguns.

Re: Zig, the Small Language

#86

Post by TakeBlaster16 »

simlevesque wrote: post #61
vinay_ys wrote: post #11

Earlier quoted context omitted.

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.

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

Re: Zig, the Small Language

#87

Post by pron »

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.

Not every language that is small (in the sense of having few rules and few primitive constructs) is necessarily simple (in the sense of easy to understand). Scheme (or its basic core) is quite small, but it's not easy to understand other people's code due to macros; RISC Assembly is also small but can be hard to understand because its abstractions are so limited. But a language that is very explicit, has reasonable abstraction, and is also small -- like Zig -- makes following the control flow quite easy, and so makes programs easier to comprehend: you mostly need to apply only local reasoning.

Re: Zig, the Small Language

#88

Post by masklinn »

llimllib wrote: post #36
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…

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`[1] is not recommended.

So why have these things as mandatory compiler errors?

Re: Zig, the Small Language

#89

Post by amelius »

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…

Yes, the linting should be in the git-commit code, not in the compiler.

Re: Zig, the Small Language

#90

Post by amelius »

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.

Small means not bloaty (yet).
Post reply on HN