libipc-old/zig-impl
Philippe Pittoli 9d875062f6 Next video: show fmt.bufPrint. 2023-02-15 15:56:14 +01:00
..
apps pongd: grooming. 2023-02-04 09:22:38 +01:00
crystal/some-crystal-app Crystal bindings: remove useless 'puts'. 2023-02-04 10:30:10 +01:00
drop Minor fix for the drop/Makefile (two '-o' options). 2023-01-17 04:42:05 +01:00
misc Code example for iterating on directory entries. 2023-01-18 13:59:11 +01:00
other Add several example programs. 2023-01-20 04:04:12 +01:00
src Zig implementation: remove useless empty line. 2023-02-06 06:09:01 +01:00
test-bindings API change: ipc_context_deinit now frees context memory. 2023-01-21 19:06:44 +01:00
.gitignore Add a few entries in .gitignore. 2023-01-18 14:02:11 +01:00
README.md Readme: what's NOT THAT great with Zig (but still cool). 2022-05-01 00:41:50 +02:00
TODO.md Zig implementation: TODO.md. 2023-02-06 10:36:25 +01:00
build.zig Zig implementation: only build static or shared library. 2023-02-06 06:06:48 +01:00
libipc.h Bindings: add ipc_close_all in libipc.h. 2023-02-03 05:46:18 +01:00
makefile Makefile grooming. 2023-02-03 05:48:24 +01:00
makefile.user Makefile grooming. 2023-02-03 05:48:24 +01:00
next-video.md Next video: show fmt.bufPrint. 2023-02-15 15:56:14 +01:00

README.md

Why rewrite in Zig

I did a library called libipc then I wanted to rewrite it in Zig.

The problems with the C-based version:

  • libipc cannot easily be ported on other plateforms
    • cannot compile under musl
    • cannot compile for any OS
    • different libc = different error codes for functions
  • cannot change the code easily without risking to break stuff
  • behavior isn't the same accross OSs
    • glibc-based and musl-based Linux have different behavior
    • Linux and OpenBSD have different behavior
  • hard to debug
    • OpenBSD has a buggy valgrind

For all these reasons, this library took a lot of time to dev (~ 2 months), and I'm still not entirely confident in its reliability. Tests are required to gain confidence. The mere compilation isn't a proof of anything. And the code size (2kloc) for something that simple can be seen as a mess, despite being rather fair.

What Zig brings to the table:

  • OS and libc-agnostic, all quirks are handled in the std lib by the Zig dev team
  • same source code for all OSs
  • can compile from and to any OS and libc
  • errors already are verified in the std lib
  • compiling foo() catch |e| switch(e) {} shows all possible errors
  • std lib provides
    • basic structures and functions, no need to add deps or write functions to have simple lists and such
    • memory allocators & checks, no need for valgrind and other memory checking tools
    • basic network structures (address & stuff)
  • structures can be printed
  • code and tests in the same file
  • (in a near future) async functions, to handle networking operations in a very elegant manner

All these features provide a massive gain of time.

And in general, just having the same standard library for all OSs is great just not to have to rely on different implementations and even locations of code and header files.

What isn't that great with Zig:

  • structures can be printed, but they also provide the format themselves, leading to an unreliable way of discovering structure's content.