On the contrary I would not call Zig very C-like at all, and that's what makes the interoperability so impressive to me.
Zig feels like a small yet modern language that lacks many of C's footguns. It has far fewer implicit type conversions. There is no preprocessor. Importing native zig functionality is done via modules with no assumed stable ABI. Comptime allows for type and reflection chicanery that even C++ would be jealous of.
Yet I can just include a C header file and link a C library and 24 times out of 25, it just works. Same thing if you run translate-c on a C file, and as a bonus, it reveals the hoops that the tooling has to go through to preserve the fiddly edge cases while still remaining somewhat readable.
> On the contrary I would not call Zig very C-like at all, and that's what makes the interoperability so impressive to me.
Zig isn't C-like in its syntax or its developer experience (e.g. whether it has a package manager), but in its execution model: unsafe, imperative, deemphasizes objects, metaprogramming by token manipulation.
Please elaborate what "execution model" entails. What is the Rust "Abstract Machine"?
I am only aware of the memory model, specifically pointer and consistency/synchronization which extends the C memory model by abstractions deemed "memory-safe" based on Separation Logic and Strict Aliasing.
In my understanding you criticize Zig for not offering safety abstractions, because you can also write purely unsafe Rust also covered by the Rust "execution model".
Rust has no inheritance typical for OOP. Zig has no token manipulation, but uses "comptime".
