Zig heading toward a self-hosting compiler

Posted Oct 8, 2020 11:23 UTC (Thu) by farnz (subscriber, #17727)
In reply to: Zig heading toward a self-hosting compiler by khim
Parent article: Zig heading toward a self-hosting compiler

IME, having worked in the sort of environment where you can't OOM safely, you don't actually care that much about catching allocation failures at the point of allocation; the Rust approach of unwind to an exception handle via catch_unwind is good enough for allocation failures.

The harder problem is to spend a lot of effort bounding your memory use at compile time, allowing for things like fragmentation. Rust isn't quite there yet (notably I can't use per-collection allocation pools to reduce the impact of fragmentation).

Zig heading toward a self-hosting compiler

Posted Oct 8, 2020 15:04 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

Yup. And as I wrote right in the initial post (just maybe wasn't clear enough): it's not even question of language design — but more features of it's standard library.

Both Rust and C++ should, in theory, support design for limited memory. Both have standard libraries which assume that memory is endless and, if we ever run out of memory then it's Ok to crash. And now, with C++20, C++ have finally got language constructs which deliver significant functionality, not easily achievable by other methods — yet rely on that “memory is endless and if it ever runs out then it's Ok to crash” assumption.

So Zig is definitely covering unique niche which is not insignificant. But only time will tell if it's large enough to sustain it.

Zig heading toward a self-hosting compiler

Posted Oct 11, 2020 17:52 UTC (Sun) by epa (subscriber, #39769) [Link]

It's unfashionable to write programs with fixed size buffers or arbitrary limits, but I think that would often be a way to get better reliability in more "static" applications where the workload is known in advance. Of course, you need to fail gracefully when the buffer is full or the limit is reached -- but you can write test cases for that, certainly a lot more easily than you can have test cases for running out of memory at every single dynamic allocation in the codebase, or even worse, being OOM killed at any arbitrary point.