That’s an implementation choice (likely a highly popular one in 64-bit systems), not a necessity. It could be a quarter (as Windows could do in 32 bit. https://docs.microsoft.com/en-us/windows/win32/memory/4-giga...) or even nothing (that’s what Mac OS X did int 32 bit. See https://flylib.com/books/en/3.126.1.91/1/), in OSes that have a 100% separate address space for the kernel.

Both these choices (and others) were available in 32-bit Linux, even after x86-64 was popular because Enterprises can be slow moving (e.g. first AMD64 CPUs come out in 2003, but it took years for some outfits to stop buying 32-bit Intel CPUs and then years more to stop putting a 32-bit OS on them)

Linux offered a conventional 2:2 split (as your parent describes) but also a 3:1 split (like Windows /3GB) and 4:4 (like OS X, plenty of address space but now context switches are very slow) but I believe it also had 1:3 (there can be cases where what you need is a lot of RAM mapped by the kernel, but you can't or won't go 64-bit) and something like 3.5:0.5 for people who hadn't learned their lesson with 3:1 ratio and needed to be kicked in the head more often.

> Half of this space is reserved for the kernel.

That’s an implementation detail - and what if your kernel is different, or you’re the one writing the kernel?

Right, the languages which have these "static integer types" are going to be more predisposed to implementing an operating system kernel or writing bare metal code that doesn't sit on an operating system.

Linux is written in C (one of these languages) and likely parts of it will eventually be written in Rust (another of them). Python, which does not bother with this (in 3.x) isn't very well suited to writing such software, although Snek ("Snek is friend!" https://www.youtube.com/watch?v=w4sWZzYysvs&t=2401s) https://sneklang.org/ is somewhat suitable for small devices.