Pied Piper middle out compression for your RAM

But seriously it's so ridiculous especially since he said it in an interview with a machine learning guy. Exactly the type of guy who needs a lot of RAM for his own processes working on his own data using his own programs. Where the OS has no control over precision, access patterns or the data streaming architecture.

Do they store 32-bit integers as 16-bit internally or how does macOS magically only use half the RAM? Hint: it doesn’t.

As a Mac programmer I can give you a real answer... there are three major differences... but before I go into those, almost all integers in native Mac apps are 64 bit. 128 bit is probably more common than 32.

First of all Mac software generally doesn't use garbage collection. It uses "Automatic Reference Counting" which is far more efficient. Back when computers had kilobytes of RAM, reference counting was the standard with programmer painstakingly writing code to clear things from memory the moment it wasn't needed anymore. The automatic version of that is the same, except the compiler writes the code for you... and it tends to do an even better job than a human, since it doesn't get sloppy.

Garbage collection, the norm on modern Windows and Linux code, frankly sucks. Code that, for example, reads a bunch of files on disk might store all of those files in RAM for for ten seconds even if it only needs one of them in RAM at a time. That burn be 20GB of memory and push all of your other apps out into swap. Yuck.

Second, swap, while it's used less (due to reference counting), still isn't a "last resort" on Macs. Rather it's a best practice to use swap deliberately for memory that you know doesn't need to be super fast. A toolbar icon for example... you map the file into swap and then allow the kernel to decide if it should be copied into RAM or not. Chances are the toolbar doesn't change for minutes at a time or it might not even be visible on the screen at all - so even if you have several gigabytes of RAM available there's a good chance the kernel will kick that icon out of RAM.

And before you say "toolbar icons are tiny" - they're not really. The tiny favicon for beehaw is 49kb as a compressed png... but to draw it quickly you might store it uncompressed in RAM. It's 192px square and 32 bit color so 192 x 192 x 32 = 1.1MB of RAM for just one favicon. Multiply that by enough browser tabs and... Ouch. Which is why Mac software would commonly have the favicon as a png on disk, map the file into swap, and decompress the png every time it needs to be drawn (the window manager will keep a cache of the window in GPU memory anyway, so it won't be redrawn often).

Third, modern Macs have really fast flash memory for swap. So fast it's hard to actually measure it, talking single digit microseconds, which means you can read several thousand files off disk in the time it takes the LCD to refresh. If an app needs to read a hundred images off swap in order to draw to the screen... the user is not going to notice. It will be just as fast as if those images were in RAM.

Sure, we all run a few apps that are poorly written - e.g. Microsoft Teams - but that doesn't matter if all your other software is efficient. Teams uses, what, 2GB? There will be plenty left for everything else.

Of course, some people need more than 8GB. But Apple does sell laptops with up to 128GB of RAM for those users.