this approach gets me really interested. What are the improvements i should expect in zig compared to C ? And how does zig stdlib compare to something like the go stdlib ( which to me remains the gold standard)
https://ziglang.org/learn/overview/
>And how does zig stdlib compare to something like the go stdlib
the stdlib is still work in progress and not the current focus of development. right now things get added to it organically (ie things needed by the compiler itself, the toolchain, or as a proof of concept for other important functionality, like an event loop). as we move forward we will have a phase where we make a final decision on what should stay in, what should be improved, and and what should be cut.
In the meantime you can quickly get a feel for what's in the stdlib by browsing the online docs:
If you'd be interested in a hash function like CRC32 you can see in the source code that there is no dependency on arch specific functionality, which makes it likely that it will work fine on other (LE?) architectures. This is on a case-by-case basis at the moment though. The advice from the Zig community is to check the source code in case of doubt. I have always found the source to be accessible, so this hasn't been an issue for me.
this is the most up to date support table for Zig:
https://ziglang.org/download/0.10.0/release-notes.html#Suppo...
Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ?
I'm honestly halfway to try and prototype some cross-platform lib for my mobile app using zig, but this part is really the one that bugs me. I'm fine with having no GC or no ARC like go or swift, (and i'm ok with no ownership mechanim like rust), but seeing absolutely nothing new since C on that side is both a surprise (since zig has improved other aspects like slices and fat pointers), and a worry.
That said, the main feature that Zig offers for avoiding those mistakes are defer and errdefer, those really go a long way in avoiding mistakes, while also keeping things simple and explicit, which also helps avoid bugs.
ArenaAllocator is another thing that helps with memory safety, depending on what you're doing.
Finally, having to pass an allocator explicitly to all the things that need to allocate also helps with that: if you have an allocator to a struct when initing it, then you know you will most probably have to call its deinit method once you don't need it anymore.
In general you probably need to learn about custom allocators and how different kinds can help you manage your memory. This applies to pretty much any lower-level language, but Odin, Zig, C++ and a few others have explicit support for this in their standard libraries.