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

241–250 of 429 posts

Re: Zig, the Small Language

#241

Post by augustk »

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.

"Wirth’s philosophy of programming languages is that a complex language is not required to solve a complex problem. On the contrary, he believes that languages containing complex features whose purposes are to solve complex problems actually hinder the problem solving effort. The idea is that it is difficult enough for a programmer to solve a complex problem without having to also cope with the complexity of the language. Having a simple programming language as a tool reduces the total complexity of the problem to be solved."

    -- Warford J.S. (2002) The BlackBox Framework

Re: Zig, the Small Language

#242

Post by mirekrusin »

oconnor663 wrote: post #168
kbd wrote: post #27

> It’s a very appealing language to the modern low-end (and not only) applications Current $work language is Go, which is so painful to use. I often look wistfully at all of Zig's features that improve on what Go does (particularly with regard to error handling). I hope in the future I can use Zig as a Go replacement and not just a C/C++ replacement.

> I hope in the future I can use Zig as a Go replacement I've only scratched the surface of Zig myself, but my impression is that replacing Go with Zig will probably be painful in most cases. I think of the stereotypical Go project as a backend API service, where memory is relatively plentiful, and "make a copy of this string" is something you do all the time without thinking twice about it. It seems like Zig wants y…

Strings are immutable in go so they don't need to be copied?

https://go.dev/play/p/o-ly05_Q46E

Re: Zig, the Small Language

#243

Post by ironmagma »

mirekrusin wrote: post #228
ironmagma wrote: post #71

Earlier quoted context omitted.

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.

Right, and I didn’t mean to imply that it did. But languages like Smalltalk do unlock power.

Re: Zig, the Small Language

#244

Post by chongli »

avgcorrection wrote: post #220
IIAOPSW wrote: post #127

Earlier quoted context omitted.

I must confess I had to suppress my knee jerk urge to downvote. It almost feels like you're asking "what's the appeal of elegance?" "What's the appeal of Chess, if you want complex gameplay just have complex rules." It almost feels alien that someone couldn't get it. Here's a simple but perhaps disappointing theory. Painting with a broad brush for a moment, there are primarily two sorts of thinkers: memorizers and lo…

What a lame Mars/Venus theory. Language designers never make complex features in order to have more to learn and catalogue. They are nakedly compromises which are supposed to make certain things easier, maybe even simpler in certain senses (for example simpler library code: more complex features like pattern matching can make for less spaghetti control flow). Then the retort might be “but they wittingly or unwittingl…

There are plenty of people who love chess but hate opening theory. They look to variants such as chess960 to get their logician fix on. They also tend to love Go (the board game) and perhaps even Stratego (which has such a game tree that dwarfs the rest).

Re: Zig, the Small Language

#245

Post by Graziano_M »

sl3dge78 wrote: post #134
Graziano_M wrote: post #95

Earlier quoted context omitted.

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.

Ah, I hadn't thought of that analogue, but it makes sense, then. It sort of recreates the opportunity to make the common bug, though, of allocating enough for the data but not the sentinel (or enough for the string but not the null terminator).

Re: Zig, the Small Language

#246

Post by mirekrusin »

Cyberdog wrote: post #211
Jarred wrote: post #142

If you want to build stuff using Zig full-time, Oven ( https://oven.sh ) is hiring Zig engineers. Email jarred@oven.sh to apply

Would love to hear your experiences hiring devs and building projects in a new, scarcely-used language and ecosystem like this. I imagine you don't quite get the range of applicants you'd see hiring devs for Rust or Go or other trendy languages du jour, but maybe that's actually a good thing since it weeds out less experienced devs and résumé liars who probably don't even know Zig exists…?

Counter intuitively you'll get really good people and won't have problem hiring? At least that's what happened years ago at Jane Street with OCaml.

Re: Zig, the Small Language

#247

Post by chongli »

geodel wrote: post #238
chongli wrote: post #234

Earlier quoted context omitted.

So don't use Zig? I see this comment a lot in response to feedback: "Don't like it? Don't use it!" Every single time, it reads to me as "stop complaining!" For as many times as I've seen the comment, I haven't been able to read it any other way. Am I being uncharitable or is it really just a clear-cut attempt to silence debate?

Well it would depend on context. For a FOSS software in domain where there are tons of other options, it is much easier to use what one likes and ignore what one doesn't. So calling it silencing the debate sounds too strong when software in question is not some controlling the world type. On the other hand in case cloud services like those provided Google/FB/Twitter/Cloudflare etc it is much more difficult to just go…

"Don't like it? Just fork it!" is a variant I see a lot in the FOSS world. It's equally pernicious in my view. Either you end up maintaining your own fork that nobody uses (and who wants to do that) or the fork is successful and half the community starts hating you for causing more fragmentation. Perhaps the most recent example of this I can think of is neovim, though in the language world python 2 vs 3 is so infamous that people have started hating the entire community from the outside.

All of this says to me that Zig is taking the wrong approach. Making highly controversial, opinionated features the standard with no way to opt out just leads to these endless debates. Languages (or any tools, for that matter) that stay out of the debate and just give everyone a flag tend to have much more welcoming communities.

Re: Zig, the Small Language

#248

Post by kristoff_it »

Graziano_M wrote: post #245
sl3dge78 wrote: post #134

Earlier quoted context omitted.

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.

Ah, I hadn't thought of that analogue, but it makes sense, then. It sort of recreates the opportunity to make the common bug, though, of allocating enough for the data but not the sentinel (or enough for the string but not the null terminator).

Not really, the sentinel is part of the type and the allocator interface in Zig is type-aware, meaning that you can't simply "forget" about sentinels. The type system will fight you.

Re: Zig, the Small Language

#249

Post by azakai »

pcwalton wrote: post #222
kristoff_it wrote: post #213

Earlier quoted context omitted.

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

Is the marker the critical thing here, though? I just wrote in another comment that I think the Zig compiler can warn about using an unsafe pointer.

The critical thing, I believe, is that unsafe can be discovered and audited. Unsafe pointers have a different type in Zig, so they are separable from the rest of the language, unless I'm missing something.

The bottom line is that in a memory-safe language it should be possible to find all the unsafety and reason about it. For spatial memory safety that's not possible in C, but it is in Zig.

Re: Zig, the Small Language

#250

Post by latchkey »

jstrong wrote: 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.

I kind of care... I have a binary that I distribute (once and update a lot) to 20k+ servers across multiple geographic datacenters... some of the servers are 100mbit only, so even updating all of them at once, saturates the network and slows everything down.

I use golang with all the size optimization steps that I can use... it makes a difference to make the binary smaller... it doesn't have to be minimal, but 4megs is better than 10megs.

Post reply on HN