Richard’s style of writing is less similar to mine than Andrew’s or Mitchell’s: he reads as a bit more generous and takes time to say things that I might just leave to a reader to notice.
Excellent move, to move up this blog post ahead of the 0.1.0 announcement, given current events
Anyway, all in all a great read. Interesting insights into the way a project’s design helps it fit into one language better or worse than another. After all this talk about tracing GCs, I’m positively itching to write a language with one in Zig and see why it’s so fiendishly difficult!!
I see stuff like this and then suddenly it seems tantalizing fun:
Granted, these tricks are sort of a like “rest of the fucking owl” situation, and I’m sure the rest of the owl bites, but optimizations like this are really cool.
As discussed earlier, having full control over allocations and deallocations is what I want in our compiler’s implementation. And in tests, I also appreciate the testing allocators detecting leaks—it can even detect leaks in compiled Roc code! Unfortunately, to get that benefit requires a lot of “init this, defer deinit” code in tests that has to be correct or else the test fails on a memory leak. None of that is necessary in Rust. I care more about the compiler’s implementation being the way I want it than the tests looking nicer, but in a perfect world I could somehow have both.
For this purpose I normally just create a local arena for the test local data which I need as parameters and the like for the the actual function I want to test.
I don’t really have a simple example, but I guess this one works? This test isn’t supposed to check for leaks or anything else, just that it creates the correct argv for spawning a process.
The output to stderr is to make debugging easier since the test failed, but it’s kinda hard to know which value is wrong. (This codebase is still on 0.15.2.)
Was going through the Roc code and it seems that my prediction was right. Due to the std.posix removal, people are now resorting to this and only mainstream systems are being supported, even though this could be trivially done as POSIX/Windows split if the wrappers stayed in the library. It’s a real shame that people will have to reimplement this stuff over and over again.
Thanks for sharing! It seems like having to init/deinit an allocator for each test is exactly what Richard was lamenting, so I wonder if you could do that setup/teardown only once for a whole set of tests, to cut down on boilerplate?
(I’m new to Zig - only just started ziglings - so forgive me if that’s a naïve question!)