Obsolete
/
libipc-old
Archived
3
0
Fork 0
This repository has been archived on 2024-06-18. You can view files and clone it, but cannot push or open issues/pull-requests.
libipc-old/zig-impl
Philippe Pittoli 9fabcbdc3c Crystal bindings: fix rx buffer in 'read' fn. 2023-02-03 16:05:01 +01:00
..
apps
crystal/some-crystal-app Crystal bindings: fix rx buffer in 'read' fn. 2023-02-03 16:05:01 +01:00
drop
misc
other
src Zig bindings: close_all. 2023-02-03 02:08:31 +01:00
test-bindings API change: ipc_context_deinit now frees context memory. 2023-01-21 19:06:44 +01:00
.gitignore
README.md
TODO.md
build.zig
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

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.