Hacker News Reader

Comment by kristoff_it | Hacker News Reader

The Zig build system is now able to run tasks in parallel. To avoid overloading the system (ie to prevent OOM) it asks you to define MaxRSS for each task, resulting in pretty sweet usage consumption: https://ibb.co/FW9kpxT

On a M1 Ultra studio (the same from my screenshot above) it takes me 6 mins to run the entire compiler test suite for arm64-linux (I do development in a Linux VM), which is pretty sweet.

Note that this is one stepping stone for getting good performance from Zig, but it's not yet incremental compilation with in-place binary patching [1]. That's still a work in progress.

[1] https://kristoff.it/blog/zig-new-relationship-llvm/

View on HN

Is it possible to use zig without the zig build system, in order to slowly integrate a new language in an existing program?

For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?

If I understand your question it is:

Is it possible to write zig modules which would be liked to the bigger project otherwise written in C, C++ & c?

And moreover, to produce C "blobs" from zig sources which would be then part of the bigger project written in other languages?

I'd also like to know the answer to both!

> For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?

It's possible, but:

1. The C backend isn't 100% there yet. You won't be able to use all features and might run into bugs.

2. The generated code won't be very readable, it's arguably not too different from just using Zig-compiled object files directly in terms of "opaqueness" and legibility.

If neither of these are a big problem for you (both points are likely to improve with time), then yes, you could do that.

Readability is not an issue, as long as there are #line directives and symbol names are preserved so it is possible to use gdb.

The idea would be that if C files are reproducible across multiple environments (esp. 32 vs 64 bit) the end user would not need a zig toolchain.

To supply a data point: As of Zig 0.11.0-dev.2615+0733c8c5c, on an x86_64-linux host, the C backend is passing 1568 behavior tests compared to 1587 behavior tests passed by the LLVM backend on the same host. So, yes, it is not 100% there yet - it is 99% there :-)

Ah, good to know! My main sources were the release notes and occasionally your tweets (the account seems to have gotten suspended?), so my information was understandably a bit out of date. Glad to see progress being made though.

I feel like Zig can dominate the shellcode space, especially with pluggable allocators and minimalism. Is there any work towards outputting a naked payload for the lack of a better word? Given just the ISA, calling convention etc., producing something that starts from main() and does nothing but what is contained within main?

Totally, just use `zig cc` as an in-place replacement for clang and move forward from there as you feel comfrotable. I wrote a blog post about this approach: https://kristoff.it/blog/maintain-it-with-zig/

I am asking for the opposite, i.e. keep everything as is and only add 2-300 lines of zig.

In particular, I explicitly don't want to rewrite 15000 lines of build system code, so anything that uses build.zig is a nonstarter.

You can invoke Zig without build.zig:

    zig build-obj file.zig

And then include the object file along with your other sources. How you do this will of course depend on your build system.

Just want to say your first link trigger fraud protection alert.

Reply on news.ycombinator.com