Ask HN: How would you design a Modern Operating System in 2022?
I think it&#x27;s past time that we started working on hardware machines that more closely resemble higher level languages than C&#x2F;C++.<p>It&#x27;s sometimes said that C&#x2F;C++ are so performant because they are close to the metal, but I think often at this point we&#x27;re seeing the reverse causal arrow: C&#x2F;C++ remain so performant because that&#x27;s still the &quot;virtual machine&quot; most modern processor&#x2F;computer architectures are targeting. C&#x2F;C++ ideas of memory management. C&#x2F;C++ ideas of process&#x2F;thread concurrency. No current processor architect would dare to break that model and do something in a new &quot;modern&quot; mold at the risk of sabotaging the performance of C&#x2F;C++ apps that don&#x27;t&#x2F;can&#x27;t&#x2F;won&#x27;t migrate to new paradigms&#x2F;abstractions.<p>(Arguably that&#x27;s part of the &quot;betrayal&quot; of the Meltdown and Spectre CPU timing bugs&#x2F;hacks: the CPU doing too many things to mimic a C&#x2F;C++ &quot;machine&quot; even though the raw details of the underlying concurrency model at the hardware have needed to vastly change and that abstraction break bleeding into a vulnerability. What if the hardware didn&#x27;t have to work so hard to pretend to be a very fast C&#x2F;C++ &quot;strictly in order&quot; machine? Could it be a faster machine if the abstractions it was targeting themselves were more concurrent and more secure?)<p>Lisp machines in the 70s had hardware memory garbage collectors. We&#x27;ve advanced the state of the art of memory garbage collectors quite a bit in the decades after, but few since have thought to again try to express that in hardware.<p>There have been dalliances with chipsets designed to more closely mimic the JVM (Java Virtual Machine) or CLR (Common Language Runtime; .NET&#x27;s VM) that got some play in embedded design spaces, but the common echo was that they ran C&#x2F;C++ code too slowly and were themselves labeled as &quot;slow&quot; and &quot;not very useful for general purposes&quot; (because we&#x27;ve tautologically defined C&#x2F;C++ as &quot;for general purposes&quot;).<p>It&#x27;s easy to wonder if we could escape this trap of building our hardware machines to resemble our least capable, lowest common denominator &quot;virtual machine&quot; like the C&#x2F;C++ model and push towards higher level concepts deep in hardware.<p>Lisp machines and JVM&#x2F;CLR machines all have more interesting reflectivity over live objects than C&#x2F;C++ machines. There&#x27;s at the very least component model benefits to being able to get general information about the live object states. There&#x27;s roads to more &quot;Actor&quot; based types of designs. More &quot;object-oriented&quot; possibility spaces than &quot;files&quot;.<p>If you are talking about true, &quot;clean slate&quot;, no concerns about backwards compatibility whatsoever, no concerns that interoperating with older software might need to be truly emulated and might possibly be slower in trade-off for better software design of new, non-emulated stuff, I think you might start at basic hardware assumptions and architectures. There&#x27;s so much more to experiment there that we don&#x27;t have the budget to explore if we have to continue to keep up the illusion that &quot;C&#x2F;C++ apps are fast and close to the hardware&quot; for backwards compatibility&#x27;s sake.