We (the computing industry) did the single-address thing for many years. It was terrible. Virtual memory was a major development in the robustness of computer

We (the computing industry) did the single-address thing for many years. It was terrible. Virtual memory was a major development in the robustness of computer systems because it allowed unrelated components to be isolated into separate fault domains. We (as an industry) adopted it universally, despite performance costs that were much greater than they are today. You could argue that unikernels are by definition one component, so it's fine to share one fault domain. That's easy when they're missing all the facilities that even the OP admits still need to be built. If you're going to have something like a network, a filesystem, and so on, you need tools for understanding them. It seems like you'll want an interactive environment for using those tools, along with common facilities for filtering and otherwise processing that output. And we're back where we started -- with several discrete components that are better off in separate fault domains. You can argue that the isolation is better provided by the language, and the article claims that "it’s easier to create quality tooling for something written in a single language with a decent type system that lives in a single address space". That's only true if you allow these components to be tightly coupled. But neither removing direct access to memory nor providing a rich type system magically eliminates the possibility for a bug in one part of a program to affect a different part of the program. And why should all these components be tightly coupled anyway? And besides all that, this is an argument for monoculture -- everything must use the same language and runtime environment. But different languages are better suited to different tasks. The author also claims a false dichotomy between code reuse and multiple address spaces. But it's completely possible to build common facilities for instrumentation and reporting and still have them be loosely coupled. All of this typifies a lot of my issues with unikernels: they represent a complete rejection of major advances in modern systems and software design without addressing the underlying problems that those advances were built to solve. There's some baggage in modern operating systems, but many (most?) of the major architectural decisions are the results of thoughtful incremental improvement by engineers looking at concrete problems. Let's not throw all of that away.