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

251–260 of 429 posts

Re: Zig, the Small Language

#251

Post by Arnavion »

davidatbu wrote: post #206
Cyberdog wrote: post #182

Earlier quoted context omitted.

The fanaticism of Rust devs makes me think it's probably massively overrated (see Node yesterday and Ruby/Rails the day before) and Go is associated with Google which gets a perhaps unfair but still unignorable knee-jerk reaction from me to avoid it. I don't know enough about Nim to pass judgment. Two reasons I decided to give Zig a try: The official chat channel is on IRC, instead of Discord or Slack (so the people…

I'm not at all trying to change your mind (I've never used Zig so I can't comment there), but just FYI: 1. Rust uses Zulip (ie, not Discord or Slack), 2. Rust doesn't lack for promising-looking, declarative/reactive UI frameworks: https://iced.rs/ , https://crates.io/crates/egui , for example.

>1. Rust uses Zulip (ie, not Discord or Slack),

The official Rust chat is on Discord.

Now, to Cyberdog's point, there is an IRC channel on libera (that I'm also a part of) and it's even bigger than Zig's channel, but it's "unofficial" and they did ask for an official one. Like, Zig's channel has the advantage of being a direct line to andrewrk which you won't get from the Rust channel.

Re: Zig, the Small Language

#252

Post by von_lohengramm »

edflsafoiewq wrote: post #215
avgcorrection wrote: post #205

Earlier quoted context omitted.

Maybe this becomes the equivalent of `go fmt` in 10 years. “How I learned to stop worrying and love errors-only”

We've had -Werror forever, the consensus is it's a bad idea. In addition to everything else, you can't ever change the warnings, including fixing bugs in them, without potentially breaking code.

> We've had -Werror forever, the consensus is it's a bad idea.

Says who? Package repo maintainers? -Werror is actually quite divisive.

Re: Zig, the Small Language

#253

Post by 1vuio0pswjnm7 »

The size of the compiler toolchain is similarly small.

For example, according to xbps on Void Linux, GCC is a 172MB install. Zig is only 166MB. A Clang or Golang install is twice the size of Zig. A Rust install is three times the size of Zig. And so on.

Re: Zig, the Small Language

#254

Post by titzer »

WalterBright wrote: post #37
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…

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…

In Virgil I usually do "var x = 1/0;", but there's a command-line option "-fatal-calls=", so you can crash on a call to a specific set of methods and get a stacktrace.

Re: Zig, the Small Language

#255

Post by chriswarbo »

mirekrusin wrote: post #227
chriswarbo wrote: post #111

Earlier quoted context omitted.

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?

I'd say any feature is cool if it:

- Is small/simple/principled (i.e. understandable)

- Enables many desirable programming styles or capabilities

- Complements other features: ideally working even better in combination; or at least, working in an obvious way

Algebraic effects tick all these boxes IMHO. In particular, there are many languages which feature try/catch AND for/yield AND async/await AND call/return; whereas having algebraic effects subsumes all that, turning it into library code.

Note that we can get pretty much the same thing with, say, delimited continuations; so they're also cool. However, having delimited continuations AND algebraic effects would seem redundant/bloated.

Re: Zig, the Small Language

#256

Post by titzer »

pcwalton wrote: post #174
azakai wrote: post #149

Earlier quoted context omitted.

"Not much safer" isn't fair. Zig has full spatial memory safety, which is already a huge improvement over C. The Zig type system and how idiomatic code looks also prevent various safety risks. Also, Zig panics on integer overflow, avoiding various other dangers. Zig does lack a general solution for temporal memory safety. That is a downside. But it can still have that safety in ReleaseSafe mode, at least - for exampl…

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

> I don't see much room for a new language that isn't memory-safe in 2022.

IMHO these are the only valid reasons for unsafe code in a systems language:

1. interfacing with unsafe external code (e.g. call the kernel directly)

2. implement the language runtime/GC itself

3. access hardware capabilities not exposed in the language (e.g. SIMD, GPU, memory-mapped IO, memory barriers)

These are semi-valid to bad reasons for unsafe code:

4. generate new machine code to, e.g. implement a guest language

5. explore the performance ceiling for a very specific code pattern that would otherwise be inline asm

For Virgil, I am at reasons 1 and 2. For Wizard, I am at 4 and 5.

Re: Zig, the Small Language

#257

Post by _gabe_ »

mirekrusin wrote: post #226
adamddev1 wrote: post #104

Earlier quoted context omitted.

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?

If you really want to argue about this, binary makes no sense in this scenario. There's assembly which gets assembled into machine code. Machine code for all intents and purposes is the lowest level that you would consider a language, binary by itself accomplishes nothing.

Now you can go see all the arguments about RISC vs CISC, which is the same argument. Should I have a small instruction set that bloats the final program's instruction count? Or a complex set with slower instructions?

Re: Zig, the Small Language

#258

Post by WalterBright »

bzxcvbn wrote: post #201
WalterBright wrote: post #37

Earlier quoted context omitted.

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…

Doesn't D have a debugger? Hitting F9 then F5 sounds a lot faster than fiddling around with the code, hoping that you forget to remove the assert before you go home and that you won't spend time pleasing the compiler.

Yes, gdb. I don't particularly like gdb, though.

> hoping that you forget to remove the assert

I routinely add a lot of instrumentation when developing code. I use `git diff` to remove it before committing.

The compiler builds itself fast enough that this is not a problem. I have one window on the source, the other on the build.

Re: Zig, the Small Language

#259

Post by avgcorrection »

chongli wrote: post #244
avgcorrection wrote: post #220

Earlier quoted context omitted.

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

Chess was such a good example to use in this lame dichotomy that we are now pivoting to Bobby Fischer chess and completely different games.

Re: Zig, the Small Language

#260

Post by k__ »

beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

Yes, I never got the USP of Zig.

There is Go, Nim, and Rust. All pretty modern system programming languages and some of them even close to C performance.

Post reply on HN