Zig is in the space of languages where an abstraction that decides that memory allocations are irrecoverable is not good enough.

If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, or C for that matter. Not every language should be designed to live in the space of "somehow low level but also a good choice for your basic web backend", like Rust.

Several things:

* There are many useful ways to handle it properly, and your choice depends on your program's constraints. The very small amount of friction (once you're used to it) encourages you to consider what ways to handle it are viable, such as allocating all memory at startup.

* If your strategy is to crash immediately, there is very little additional friction but you get the benefit of it being obvious in your code that this is the case.

* There are environments where memory allocation fails immediately, including if you turn off over-commit on Linux. If your hardware is dedicated to running a high reliability system, configuring it in this way is reasonable.

* Memory is not the only resource. Indeed, removing the special call out is what changed here. That different resources are handled with the same mechanism (errors, instead of eg returning null from malloc) is good.

You might have a limited budget per incoming request in a http server for example. Then you want all of the code that http handler calls to be able to handle an error of type something like OutOfMemory.

This is a very good ability to have in an application like a database.

Nearly impossible in some contexts, where the trade-off makes sense.

There are many scenarios, especially in embedded systems, where it can happen and you want to handle it robustly, e.g. by evicting a cache or flushing a buffer to disk.