Because Windows (roughly speaking) doesn't use the fork/exec model for process spawning, it doesn't need overcommit. If you use fork/exec, then overcommit is the least bad of all the bad options.
Anyway, whether overcommit is a good idea is somewhat tangential. The point is that portable programs cannot rely on being able to detect and recover from OOM in the same process. That's why you see so few programs try. (The programs that do try frequently suffer from security vulnerabilities in their OOM handling paths, ironically enough.)
> If you use fork/exec, then overcommit is the least bad of all the bad options.
vfork is better than fork/exec with overcommit.
It's interesting to me that you mention portability as an argument for why an out of memory situation should cause a crash rather than be handled like any other error.
Let's say I make a library and I want this library to be maximally portable. That means it should run in some of the following environments:
* Microsoft Windows
* embedded software
* operating system kernels
* drivers
* real-time software
In all of these environments, a library that handles out of memory correctly would be more portable than a library that panics.
If only there was a programming language that helped programmers solve this problem, while preventing the pitfalls that result in these security vulnerabilities that you mention...
The Rust team took the approach of targeting application code on the three primary Tier-1 platforms, macOS, Windows, and GNU/Linux, as the goal for API design and portability of the standard library.
Besides the standard library, it also has the core library, which is a small subset that is appropriate for all environments, even those without allocation or those with different strategies for allocation.
With this goal in mind, many of the decisions make sense. A portable application can't rely on getting errors on out of memory situations. Many people don't write code that handles out of memory, or if they do they don't test it, which can lead to significant bugs. Error handling for out of memory is cumbersome if it is required for every operation which could allocate memory, such as pushing to a Vec.
Additionally, Rust 1.0 didn't have some of the later features to make error propagation simpler, so functions which could return errors were more cumbersome to use.
For now, anyone who wants to use Rust in those situations, but still wants allocation support, needs to implement their own allocator and collections with fallible operations. Once the allocator API and fallible collections support lands, much more of the Rust standard library will be usable in such an environment.
I agree that if you're in kernel space, then you have to be able to recover from allocation failure. However, it's a waste of time for most programs (or libraries—most libraries I write can't go into kernel space for various reasons) to try to recover from OOM. Even if not memory-unsafe, it results in untested error handling paths and noisy code.
I rarely write Windows-only programs, so I can't rely on OOM handling in my logic. It's much simpler to just have the same OOM story everywhere (crash).
Most zig code still handles OOM via panic. You'd have to go out of your way to somehow make it less safe than that. Dealing with an error by passing it up the call stack (eventually to the panic handler) is actually easier than ignoring it:
//kick any error up the call stack
var buffer = try allocator.alloc(u8, 500);
//in debug builds, assert that this will not fail
//in release-fast failure will result in undefined
//behavior.
var buffer = allocator.alloc(u8, 500) catch unreachable;
The system administrator can turn it off, kind of. But a zig or rust program running in user space without privileges cannot turn it off, not even for the program itself.
