Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig 0.8.0 Release Notes

ziglang.org

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Zig 0.8.0 Release Notes

#11

Post by tialaramex »

slimsag wrote: post #5

I've been working with Zig almost 8h/day since Sept. of last year[0], and am super excited about the ideas it is bringing to low-level programming - even to C/C++/Rust. I hope folks outside of the Zig community give it a glance even if just for the ideas it brings around cross-compilation and being a nice out-of-the-box experience. Some of my favorite highlights from this release: > With the advent of the Self-Hosted…

There is a Rust code-signing implementation.

https://github.com/indygreg/PyOxidizer/tree/main/tugger-appl...

Whether you should teach Rust to code-sign your software using this code is probably a tricky question, but it appears to me that you could.

Re: Zig 0.8.0 Release Notes

#12

Post by raphlinus »

Rusky wrote: post #10

The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matri…

It's how the internal "AST" for Markdown is represented in pulldown-cmark - a Vec of a node enum. A major motivation was reducing the allocation cost (it's extremely common to do one allocation per node for this kind of thing), but another benefit is that a tricky "splice" information for inline markup (basically, moving a sequence of text spans, possibly with their own emphasis, between two asterisks into a subtree) is pretty easy to represent.

Re: Zig 0.8.0 Release Notes

#13

Post by smeenai »

I was curious about this bit from https://ziglang.org/download/0.8.0/release-notes.html#Self-H..., since I work on the new LLD for Mach-O backend:

> Additionally, it is doubtful that the new backend will allow for seamless cross-compilation to macOS since every macOS binary is required to be a PIE and link dynamically against libSystem dylib, which will require the lib's presence on the host for the lld to reference and link against.

This is true, but it's a platform requirement, not a linker requirement. How does zig's linker get around this? Does it produce static binaries (LC_UNIXTHREAD instead of LC_MAIN)?

Re: Zig 0.8.0 Release Notes

#14

Post by tialaramex »

slimsag wrote: post #4
acrispino wrote: post #3

This was a rough release cycle for downstream users of LLVM. During testing of the release candidates, we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers, the LLVM project tagged release 12.0.0. Not only were there open regressions at this time, but the 12.0.0 tag did not even tag the tip of the release/12.x branch - so there were fixes alre…

Accidents happen, and LLVM is a really large complex project with tons of downstream users (like Zig and Rust) discovering issues not caught by LLVM's test suite / clang. It's definitely a real problem[0][1][2][3], I would argue LLVM needs a longer release-candidate cycle before a release is cut - to give downstream users more to pick up and report regressions, as well as LLVM contributors to fix them. A higher quali…

It's definitely a problem that LLVM has features which are in practice not really exercised by C++ (because the ISO C++ standard says something is Undefined Behaviour) and so clang doesn't need to use those features yet LLVM developers too often act as though only C++ matters. Rust spent a while with trivial crashes if you have an infinite loop. Here's how that happened as I understand it:

From Rust's point of view infinite loops are well formed. Sure, your program never exits but that's what you told it to do, so it's your problem not Rust's.

However in C++ that isn't a thing. In C++ an infinite loop is Undefined Behaviour. And so LLVM just didn't have working infinite loop code. If your C++ program has an infinite loop, too bad the ISO Standard says your program is wrong, clang is behaving as intended. Sure that's crazy but C++ programmers have a sort of Stockholm Syndrome.

So LLVM had a bug, but because the most important customer of LLVM is clang, and clang didn't care about this hideous bug while its users had just become numbed to the consequences, the bug lived on for ages.

Re: Zig 0.8.0 Release Notes

#15

Post by jodrellblank »

Rusky wrote: post #10

The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matri…

> "his saves on allocations, saves on total memory usage"

Co-Dfns is Aaron Hsu's project, and he has a talk[1] on a compiler implemented in a nano-pass style, once in Racket, once in Chez Scheme[2] and once in Dyalog APL, each using CPU and GPU.

For compiling an AST with ~16 million nodes, he gives benchmark figures that Dyalog APL takes 64MB RAM to hold it, Racket takes 1051MB and Chez Scheme takes 1485MB. His provocative statement for the talk is "pointers are the refined sugar of programming". The APL version is 1/50th of the lines of code[4], runs typically 9x faster on the CPU, 50x-200x faster on the GPU, despite being interpreted by Dyalog vs compiled Scheme. There are benchmarks where the APL version loses in runtime, under 1k lines of code (which he calls "tiny tiny") so lots of startup overhead and not enough big arrays to gain ground on.

He has one talk (available on YouTube) about his approach to using arrays to working with tree structures in a high-performance way in APL[3].

[1] https://www.youtube.com/watch?v=UDqx1afGtQc

[2] he used to be on the Scheme R6RS steering committee, so he's not new/inexperienced with it http://www.r6rs.org/steering-committee/election/electorate.h...

[3] https://www.youtube.com/watch?v=hzPd3umu78g

[4] 17 lines of code which took a PhD researcher (him) 5-10 years to write, mind you.

Re: Zig 0.8.0 Release Notes

#16

Post by ncmncm »

The energy in this project is amazing!

The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly.

For my own purposes, IIUIC it is fatally flawed, lacking destructors, but as a raw C replacement it has legs. Compile-time execution and types as regular compile-time values makes it actually powerful.

Re: Zig 0.8.0 Release Notes

#17

Post by rajandatta »

Congratulations to the Zig team. Zig's a very interesting project for language mavens. A question - what does the Zig ecosystem look like?

Are there strong products and parsers, services, actor models, interfacing with Middleware written in Zig? Or is the theme - drop to C based interfaces to those products? What's the zen of Zig say?

What are some notable wide use applications, solutions written in Zig?

Re: Zig 0.8.0 Release Notes

#18

Post by duped »

tialaramex wrote: post #14
slimsag wrote: post #4

Earlier quoted context omitted.

Accidents happen, and LLVM is a really large complex project with tons of downstream users (like Zig and Rust) discovering issues not caught by LLVM's test suite / clang. It's definitely a real problem[0][1][2][3], I would argue LLVM needs a longer release-candidate cycle before a release is cut - to give downstream users more to pick up and report regressions, as well as LLVM contributors to fix them. A higher quali…

It's definitely a problem that LLVM has features which are in practice not really exercised by C++ (because the ISO C++ standard says something is Undefined Behaviour) and so clang doesn't need to use those features yet LLVM developers too often act as though only C++ matters. Rust spent a while with trivial crashes if you have an infinite loop. Here's how that happened as I understand it: From Rust's point of view i…

If we're throwing stones at LLVM features that don't work let's toss one at noalias

Re: Zig 0.8.0 Release Notes

#19

Post by lenkite »

slimsag wrote: post #5

I've been working with Zig almost 8h/day since Sept. of last year[0], and am super excited about the ideas it is bringing to low-level programming - even to C/C++/Rust. I hope folks outside of the Zig community give it a glance even if just for the ideas it brings around cross-compilation and being a nice out-of-the-box experience. Some of my favorite highlights from this release: > With the advent of the Self-Hosted…

I really, really wish Zig had RAII. I am so used to this in C++ and have grave difficulty living without it. But it has been shot down as RAII is considered a high-level feature. Well, I guess I will admire the language from a distance but I am unlikely to use it practically.

https://github.com/ziglang/zig/issues/782

Re: Zig 0.8.0 Release Notes

#20

Post by dnautics »

ncmncm wrote: post #16

The energy in this project is amazing! The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly. For my own purposes, IIUIC it is fatally flawed, lacking destructors, but as a raw C replacement it has legs. Compile-time execution and types as regular compile-time values makes it actually powerful.

> lacking destructors

seriously? write a `deinit(self: *Self)` function into your struct and explicitly call `defer obj.deinit()`. Explicit is better than implicit. And the penalty? One line of code per destroy site, plus writing the `allocator.destroy(self)` line in your deinit method. As a result of being explicit, SO many headaches are solved. What are the rules again when you have a C++ class that polymorphically inherits destruction? What were the override rules, if your child class needs to implement its destructor? What order do destructors trigger when there's more than one for stack-objects? what about in std::vector?? What about in std::map??

Post reply on HN