Zig 0.7.0 tagged | Hacker News Reader

Zig 0.7.0 tagged

ziglang.org

90 pointsjedisct145 comments

"Zig 0.5.0 introduced async functions. This feature has no dependency on a host operating system or even heap-allocated memory. That means async functions are available for the freestanding target.

Zig infers whether a function is async, and allows async/await on non-async functions, which means that Zig libraries are agnostic of blocking vs async I/O. Zig avoids function colors."

Nice! I had the impression that Zig wasn't so simple as I've imagined it due to features like this, but this actually sounds like a lot of thought was put into this to adhere to Zig's principles. Looks cool!

See https://kristoff.it/blog/zig-colorblind-async-await/ for more information about Zig's “Colorblind” Async/Await.

Thanks, I got from this a nice reading, a new video for my watch list, and a new Twitch channel to follow... not bad!

Finally

I don't have the release notes done yet but we're doing a live release party on twitch right now: https://www.twitch.tv/kristoff_it

Edit: it's over now. I'm still working on the tarballs and release notes.

Oh, uBO doesn’t block the ads there.

Yeah, over the past month a war of sorts has been breaking out amongst ad blocker users and Twitch. So far, Twitch has been winning.

This user script works for me: https://gist.github.com/pixeltris/77c676ef65b0b76e7aa56d8a0e...

https://ziglearn.org/ should be up to date for 0.7.0 already. Do have a peak if you haven't yet learned how to use Zig; the first chapter (most of the language) should be readable in under an hour.

So is the following paragraph (that shows up after the first couple of paragraphs) there for future-proofing the guide, or a sign that updated guide hasn't actually been released yet? Because both interpretations sound reasonable to me

> This guide assumes you’re using a master build of Zig as opposed to the latest major release, which means downloading a binary from the site or compiling from source; the version of Zig in your package manager is likely outdated. This guide does not support the 0.7 build of Zig.

For future proofing, I just don't want to exactly support tagged releases as of now. Zig could release breaking changes next week and I would update the guide to fit that; master is followed.

I was actually going to submit the Zig Newsletter link [1], but I gotta say, randomly talking about another language that is not even released is baffling.

[1] https://buttondown.email/ZigSHOWTIME/archive/e83ee9c5-53e0-4...

Hi that's the newsletter I write and it's not an official thing. That passage is based on my personal experience of watching other projects that I deem reputable (i.e. Jai, Handmade Hero) and doing the very basic thing of looking at how they are doing compared to us.

Jonathan Blow is a very smart individual, in a sense that goes way past his programming ability (as exemplified by the fact that 2 out of the 3 talks of his that I link to in the newsletter are not about programming), that said he has approached the development of Jai in a diametrically opposite way compared to what Zig is doing.

We have a full-fledged OSS project with contributors, PRs, etc; while JB, while IIRC he plans to open-source the code eventually, does development in private and even got to the point of refusing to showcase new features he's adding because he doesn't want other projects to copy him.

Clearly there is a philosophical disagreement there between Zig and Jai, but, as I said earlier, I really think Jai is a valid project and as such I'm not dismissive of those disagreements.

On our side of the argument we have a constantly increasing number of contributors, so the point I was making in the newsletter is that it really means something, because, at least according to my perception from watching JB's streams, we're moving at a faster speed.

I've personally learned a lot watching Casey and John stream themselves coding (Casey also started a youtube channel on legal cases, which is another very interesting watch), but they're not perfect and in the specific case of developing in the open vs developing in a cave, I think I have a priviledged PoV where I can raise valid criticism.

Does everything we write on the internet have to be investor-friendly? Fuck I hope not.

I don't really understand why it makes sense to spend most of a newsletter about zig 0.7 complaining about another language, instead of the cool stuff about ziglang. They're similar in that they're both "better Cs" but their targets seem pretty different.

> Does everything we write on the internet have to be investor-friendly? Fuck I hope not.

I don't see it at all reflective about "investor-friendly" but more the existing community around the language. It's great that zig's is active, but if some of the major community members spend seemingly equal/the majorityu of something like a newsletter about a fairly big development release being incredibly negative toward another project while pretending to be respectful, eh.

I'm not saying you have to cater to me, since I'm a nobody, but this and a few other things about the zig community have made me less interested in spending my limited free time playing with it.

> being incredibly negative toward another project while pretending to be respectful

So you don't refute any of my points about the available information on Jai, but you instead dismiss my entire argument a priori, classifying it as a farce. Ok.

It doesn't matter if you're right or wrong about Jai. I just don't understand what it had to do with a ziglang release.

Come on! You didn't even list all the cool new stuff in Zig 0.7.

Can anyone with more experience elaborate on the pros and cons of Zig Vs Rust for systems programming? For example are there any efforts to write an OS in Zig?

https://scattered-thoughts.net/writing/assorted-thoughts-on-...

I like the way you structured your blog post. Quite minimal and easy to skim. My only suggestion might be to give each section a small title.

Zig doesn't prevent memory errors, or data races at compile time, but Zig does handle undefined behavior better than C/C++, and has options instead of nulls. So you get some sized step in the right direction on correctness, without adding the complexity of a borrow checker. Zig compiles faster, Rust is more mature of an ecosystem. Zig is a simpler language, Rust is featureful/more complex.

To me Zig seems to be an in-between between C and Rust. It feels a lot more modern and pleasant to use than C without the rather large complexity of Rust. Of course, nothing comes free, so it's also less safe than Rust.

I personally really enjoy Rust's commitment to safety and I do find that the difficulty of writing Rust code that will pass the borrow checker and its stricter type system is well worth it but I know that some people find it frustrating and not very pragmatic. If you fall in this camp then Zig might well be worth a try.

Basically coming from C if you think that Rust goes too far, try Zig. If you think that Zig doesn't go far enough, try Rust.

Zig's C integration story is pretty compelling - https://ziglang.org/#Integration-with-C-libraries-without-FF...

You can call C code from Rust as well but it's not as tightly integrated into the language (and probably can't be, since C code is inherently unsafe).

I would like to read about Zig vs Nim.

Yes, the comptime stuff I read about Zug sounded like Nim to me.

Nim is garbage collected, Zig is manual

As far as I know Nim is both.

Generally Zig is a bit lower-level and simpler. One big difference is that Nim compiles to C whereas Zig compiles to LLVM IR. Zig is also heavily imperative / procedural, whereas Nim supports more object-programming paradigms, algebraic data types, more sophisticated exception handling, and so on.

They are both low-level compared to Python but fill different niches.

If anyone ever considers writing a Nim variant that compiles to Zig, I suggest that it be called "Zinnig". Aside from being punny it means sensible/rational in Dutch, which seems appropriate ;)

[0] https://en.wiktionary.org/wiki/zinnig

> low-level compared to Python

In what way? Nim gives full access to hardware, memory management & co, but the expressiveness is very similar to Python.

"Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C. "

Whoa, whoa, whoa. UB on unsigned!? Best of luck.

It’s checked in debug modes (overflow is a runtime error). You can explicitly use the overflow operator (+%) if you know that’s the behavior you want.

In ReleaseSafe mode, too.

Fine, but the bugs this will cause when people port code across from C or C++... probably painful.

So, to be safe people should build both Debug and Release?

Develop in debug mode, deploy in safe release mode, and when you're absolutely sure that everything is safe, you can switch to the fast release mode.

It is also possible to selectively disable/enable safety for individual code blocks.

It's going to be a real strategy to write your code in releasesafe, identify hot code, and mark it off as releasefast on a function by function basis

Alternatively, there may be unfound overflow bugs in that C/C++ code.

Worth noting that UB is also checked in ReleaseSafe mode. Related issue: https://github.com/ziglang/zig/issues/2301

Only with signed ints, since unsigned overflow is defined behaviour.

probably deploy in saferelease mode always unless you are making something like a single player video game, or that otherwise has incredible performance needs but does not deal with untrusted data.

There's slightly different looking operators if you want explicit overflow behaviour, where it's not UB.

I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing. Because for 99% of code performance is secondary to correctness. The compiler should only do that when requested.

A point: Benchmarks produce metrics measured in seconds. Bugs don't produce metrics you can measure but the costs are unbounded.

>I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing.

Aren't you contradicting yourself here?

And I do think that some UB optimizations make a lot of sense. Actually if you look at the way Rust does it, it gets rid of many UBs not by adding checks for them but by explicitly forbidding the UB condition to occur in safe code (therefore "optimizing on UB" by enforcing that the UB condition cannot happen in correct code, not by adding checks for it and slowing things down). That's why for instance pointer arithmetic is unsafe in Rust, since arbitrary pointer offsets can lead to UB.

Although I agree that there are a few C UBs that I think ought to be relaxed because they don't make a lot of sense for modern architectures though (signed overflow being the main one).

I just draw on firmware that I write for micro-controllers. Most of the code isn't in a hot path. There is probably 100 lines worth out of 50,000. That's what I mean by optimizing on UB by default at least in my case seems wrong. I'm also in the apposite situation from a web service where if a worker thread hangs you just kill it and restart it. And you can push update to the cloud.

Bringing up signed overflow. I did some tests once flipping back and forth between using a int and an unsigned int and wasn't impressed with the speed up. I've also done tests with aligned and an packed data structures and on a modern processor, also not impressed.

> Aren't you contradicting yourself here?

I don't think it's a contradiction. I think what's being said is that it's the wrong default, i.e. the special different-looking operators should be the ones with UB, not the obvious "normal"-looking ones.

Exactly. At least my experience there is code where you really care about performance and you are willing to do the distance. And then there is a lot of code where you just want it to work with no surprises.

Reply on news.ycombinator.com