> Comparing the comprehensive Win32 API reference against the incidentally documented Native APIs, its clear which one Microsoft would prefer you use. The native API is treated as an implementation detail, whilst core parts of Windows' backwards compatibility strategy are implemented in Windows subsystem.

> A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

Zig clearly doesn't actually care that much about building robust and reusable software if they're going to forgo Microsoft's decades-long backwards compatibility functionality for the dubious gains of using bare-metal APIs.

The Zig maintainers clearly think that keeping up with the undocumented native API is less headache than using the documented but notoriously inelegant win32 API.

This might very well be a good idea. Microsoft is not going to change a vital piece of their OS just on a whim. I would wager that even if they wanted to, they would not be able to do so that easily. A large organization maintaining a large software with a billion users just does not move that fast.

They defer all very real issues caused by their approach as being problems for others to solve (wine, antiviruses, users, even microsoft). That's such a weird level of hubris.

I think the only place where avoiding win32 is desirable is to write drivers, but zig already has support for some level of bare-metal development and I'm sure a package can provide shims to all ntdll utilities for that use-case.

I think it's pretty clear that they're doing it because it's a more fun challenge. As a low-level developer myself, I agree that using the lowest-level API possible is fun, especially if it's poorly documented and you have to try to try to preemptively mitigate breakage! But this is no mentality to have when you're writing a language ecosystem...

lately it feels like zig is attempting to speed run irrelevance. which is a shame.