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?
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