Hi, > What actual concrete benefits would Zig have for the guix project, > especially compared to guile?
Rewriting some components in zig is my long term target. My first target is reducing the code base size and make it more modularity. I have done some experiments on it [1][2]. Lots of code on nix directory of guix can be replaced with C++’s standard library. I summarize the key components of nix inside guix as following: 1. Nix Archive (nar) manipulation 2. .drv files manipulation 3. read/write to store (/gnu/store) 4. garbage collection of store (guix gc) 5. management of real build events 6. communicating to sqlite3 In ideal situations we only need 6 pairs of .cc and .hh files. If I can really finish this work these 6 modules can be easily rewrite either in zig or guile. And before guile-daemon can really be used, we can have a more clean codebase that can be investigated more easily. Recently openSUSE’s security team helped GNU screen to detect many security issues [3]. We may can invite openSUSE to do the same check for guix. A smaller codebase also means the compiler can more easily to genetate more efficient machime code. As for the guile-daemon, I am also waiting for it. I don't want to create any obstacles for it. As I asid in [4]: > I don’t plan to add any new functionality using C++ or replace current > codebase using some fancy new features of C++. Originally I plan to submit changes sequentially to guix, but Ludo has a mostly conservative though on my project [5]. So maybe I will do it alone. [1]: https://lists.gnu.org/archive/html/guix-devel/2025-05/msg00210.html [2]: https://codeberg.org/congcongkuo/guix-daemon-zig/commit/38b8722f53d17ae4c5826dab051f4fdb00da31db [3]: https://security.opensuse.org/2025/05/12/screen-security-issues.html [4]: https://lists.gnu.org/archive/html/guix-devel/2025-05/msg00215.html [5]: https://lists.gnu.org/archive/html/guix-devel/2025-05/msg00214.html
