Presumably the idea is that lots of things that you basically have to use C++ for today because C alone is weak could be served by Zig instead, not that Zig and C++ are comparable languages.
I really like Zig, but the lack of RAII means we're back to malloc/free style programming, and I would never opt into that unless Rust could not be used (e.g. binary size too large). Having said that, it's way better than C and I hope it does well.
Unfortunately malloc-free is unavoidable if you're writing code that needs to allocate memory rather carefully (e.g. guaranteeing no OOMs—Rust has many situations where it'll silently heap alloc and then panic on OOM). Looks like Zig has accepted that it'll be used for those situations and decided to make that experience really good, instead of deciding to be a rustalike or insist on RAII. I think that's an appropriate choice! It makes me excited to use C less.
RAII and explicit allocators are independent concerns. That Rust chose a bad default in having 1) a static global allocator, and 2) an expectation of infallible allocations from said global allocator that was then made pervasive in its libstd and third-party ecosystem, has nothing to do with the fact that it has lifetime-based destructors. Having explicit allocators does not mean you need to `free` manually instead of via an automatically-called destructor. A type that allocates needs to ensure a corresponding free in its dtor, and then every other code that uses the type gets the lifetime-based cleanup for free.
I imagine that Zig has a lot more focus on "I can't use X in my environment" types of situation. It seems that for many such situations it might be a better fit than Rust.
There is, for practical purposes, noplace where one can't use C++, except where gatekeepers exercise power keep it out. Typically it would be only a day's work to get those building with a C++ compiler, whence they could begin modernizing.
There are plenty of loadable modules in C++ for Linux and BSDs, and plugins for Postgres, in places where there is no expectation of upstreaming them.
Since the Zig tool chain can also compile C, and Zig can use C headers without translation, the cases are more similar than one might otherwise suspect.
But of course it would be less of an upgrade, and the Zig parts would have to stay clearly segregated.
Not really back to that. Zig just chooses a different way to deal with memory, namely different compilation modes and faster write-compile-test cycles.
It’s a different tradeoff which may be worth it for some use-cases. But it’s definitely not obvious whether it is worse, as the alternative comes with a huge complexity on the language side.
It is possible they will add a type level resource release obligation at some point. It would not be anything quite like the Rust borrow checker but I think would be a big help. https://github.com/ziglang/zig/issues/782
