I've heard Rust classified as Safety, Performance, Usability in that order and Zig as Performance, Usability, Safety. From that perspective the build speed-ups make sense while an interpreter would only fit a triple where usability comes first.

This is why the value proposition of Zig is a question for people, because if you got measurably better performance out of Zig in exchange for worse safety that would be one thing. But Rust is just as performant, so with Zig you're exchanging safety for expressivity, which is a much less appealing tradeoff; the learning from C is that expressivity without safety encourages programmers to create a minefield of exploitable bugs.

Zig is a lot safer than C by nature. It does not aim to be as safe as Rust by default. But the language is a lot simpler. It also has excellent cross-compiling, much faster compilation (which will improve drastically as incremental compilation is finished), and a better experience interfacing with/using C code.

So there are situations where one may prefer Zig, but if memory-safe performance is the most important thing, Rust is the better tool since that is what it was designed for.

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.

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.

It's value proposition is aiming for the next generation of system programmers that aren't interested in Rust like languages but C like ones.

Current system devs working on C won't find Zig or Odin's value propositions to matter enough or indeed as you point out, to offer enough of a different solution like Rust does.

But I'm 100% positive that Zig will be a huge competitor for Rust in the next decade because it's very appealing to people willing to get into system programming, but not interested in Rust.

> expressivity without safety encourages programmers to create a minefield of exploitable bugs.

Also, psychologically, the combination creates a powerful and dangerously false sensation of mastery in practitioners, especially less experienced ones. Part of Zig's allure, like C's bizarre continued relevance, is the extreme-sport nature of the user experience. It's exhilarating to do something dangerous and get away with it.

Zig is not an extreme sports experience. It has much better memory guarantees than C. It's clearly not as good as rust if that's your main concern but rust people need to also think long and hard about why rust has trouble competing with languages like Go, Zig and C++ nowadays.

What's the use case for Zig? You're in that 1% of projects in which you need something beyond what a garbage collector can deliver and, what, you're in the 1% of the 1% in which Rust's language design hurts the vibe or something?

You can also get that "safer, but not Safe" feeling from modern C++. So what? It doesn't really matter whether a language is "safer". Either a language lets you prove the absence of certain classes of bug or it doesn't. It's not like C, Zig, and Rust form a continuum of safety. Two of these are different from the third in a qualitative sense.

You want a modern language that has package management, bounds checks and pointer checks out of the box. Zig is a language you can pick up quickly whereas rust takes years to master. It's a good replacement to C++ if you're building a game engine for example.

> Either a language lets you prove the absence of certain classes of bug or it doesn't. It's not like C, Zig, and Rust form a continuum of safety. Two of these are different from the third in a qualitative sense.

Again repeating my critique from the previous comment – yes Zig brings in additional safety compared to C. Dismissing all of that out of hand does not convince anyone to use rust.

I like the Julia approach. Full on interactivity, the “interpreter” just compiles and runs your code.

SBCL, my favorite Common Lisp, works the same way I think

Even with C++ and heavy stdlib usage it's possible to have debug builds that are only around 3..5 times slower than release builds in C++. And you need that wiggle room anyway to account for lower end CPUs which your game should better be able to run on.

I've never done it, but I just find it hard to believe the slow down would be that large. Most of the computation is on GPU, and you can set your build up such that you link to libraries built at different compilation optimizations.. and they're likely the ones doing most of the heavy lifting. You're not rebuilding all of the underlying libs b/c you're not typically debugging them.

EDIT:

if you're targeting a console.. why would you not debug using higher end hardware? If anything it's an argument in favor of running on an interpreter with a very high end computer for the majority of development..

This was building the entire game code with the same build options though, we didn't bother to build parts of the code in release mode and parts in debug mode, since debug performance was fast enough for the game to still run in realtime. We also didn't use a big integrated engine like UE, only some specialized middleware libraries that were integrated into the build as source code.

We did spend quite some effort to keep both build time and debug performance under control. The few cases were debug performance became unacceptable were usually caused by 'accidentially exponential' problems.

> Most of the computation is on GPU

Not in our case, the GPU was only used for rendering. All game logic was running on the CPU. IIRC the biggest chunk was pathfinding and visibility/collision/hit checks (e.g. all sorts of NxM situations in the lower levels of the mob AI).

Debug builds are used sometimes, just not most of the time.

Naturally you can abstract them as middleware does it, however it is where tracking performance bugs usually lies.