I’m a core developer on Rakudo, the Raku implementation, and I’d like to inform you of a bit of impromptu research I’ve conducted on using Zig to improve the performance of a (contrived) Raku script. It’s not a proper analysis, that will have to come later, but the initial results were too exciting not to share.
tl;dr – It’s about a 12-18x speedup at high volumes of objects to use Zig for a CRC32 check as well as to create structs on the heap for use in the Raku code.
You mentioned it in the article but forgot to include it here: a third (possible) advantage would be using zig as (one of) Raku’s C compilers in general.
As a former Perl developer / enthusiast, this was a great walk down memory lane. Cheers!
I don’t have much to say other than it’s exciting to see more language creators exploring Zig as a C alternative.
…I don’t think the function signatures need to get nearly as gnarly as they get in C.
Also the blog theme reminds me of my first-ever IDEs I was exposed to when I was a kid, Borland Turbo C++ and Microsoft QBasic. Peak 90s software dev vibes.
It’s even more than a C alternative in that I want to work out a solution with Zig. I would probably not have tried replacing the Raku objects with structs from C because I would have just bound into some library that offered CRC32 rather than assembling a hand-rolled (but stdlib-assured) one like I did in Zig.
It’s interesting to contrast Raku’s design imperatives with those of the Zig project. There is not a lot in common, the former being nominally maximalist and the latter being nominally minimalist, many ways vs one way, etc. Yet Zig ships with a batteries-included stdlib just like Raku, and everything is an expression, making it feel quite familiar to a Raku user.
I’ll have to think on it some more. It probably deserves a blog post of its own.
Really I can’t gush enough about Zig… it’s made me fall in love with programming all over again.
I can’t claim any credit for it I’m afraid! It comes as a standard theme available on bearblog.dev.