Switch from C to Zig

[plajjan]

ziggazigg aaahhh

There are many benefits to Zig over C. Overall it largely plays in the same arena as C but it seems to me that Zig offers improvements in most areas, simply being a better C.

However, that said I don't have the same level of experience writing Zig as I do writing C (not that I'm a very seasoned C-coder). How do we determine the negative sides of Zig? Can we somehow start small and that way gain some experience and possibly revert this decision before it's too late?

I think the most important aspect to plan out is how to transition from the current structs, like B_str, to something more Zig idiomatic. I don't want to end up with loads of casts so like in phase 1 we stick to current C structs, which necessitates @intcast etc on Zig side, then switch to idiomatic Zig struct after which we need to remove casts.

TODO

• plan migration
  • prioritize:
    • incremental implementation, so we can carry it out in small pieces over time
    • low work effort, i.e. not having to take multiple complete passes over the code
  • sacrifice:
    • backwards compatibility, we can do loads of changes over time and no one should really need to care
    • efficiency / optimization
      • if it's simpler to align on CPU word sizes, then we can use that instead of packing i32 or whatnot for maximum efficiency
    • portability
      • if it's simpler to align on fixed sizes on say 64 bit CPUs, then we can just focus on 64 bits CPU - we effectively only test on x86_64 and aarch64, so no biggie there
  • random thoughts:
    • c_int, c_long etc are Zig types that have guaranteed compatibility with C and so are safe across many platforms, but a c_int can align with i32 on one platform and be a i16 on another..
      • if we can pin all fields to say word size, like i64, then we remove this problem
      • maybe use comptime to assert c_int sizes to ensure consistency without casts?
    • can we generate a shim of wrappers?
• CodeGen
• rts
• builtin