dist1ll

> such the submodules of a program cannot corrupt parts of memory that belong to others

IME you can eliminate tons of issues using language-based safety. That just wasn't possible before Rust without taking a perf hit. And you can still use vm in a unikernel for e.g. guard pages, read-only segments, demand paging etc.

I'd say the main advantage of the unikernel approach is the ability to be very intentional about where/how you introduce complexity. For a certain class of high-performance systems software, that has direct implications on reliability and performance.

Unikernels simply redraw abstraction boundaries. You can still use libraries and third-party code to implement common primitives. In fact, that's exactly what many unikernel frameworks give you (unikraft, hermit, mirage)

> with about the same efficiency and just a little more code.

It depends. For some things, CPUs don't even come close. An XCVU13P FPGA can handle 1.2Tbps of full-duplex Ethernet @ 1 billion pps. And that part costs less than a grand at moderate qty, and with significantly less power consumption than a CPU that'd be capable of operating a dataplane at these speeds.

There's more to building a successful CDN business than running workloads in a testing environment.

For content delivery you can simulate the load one PoP would get. You don't need to be at Cloudflare scale to build a testbench with 800G+ of traffic at different pps.

Fwiw with ef_vi you have full control over the event queue - you don't need to busy-spin it, you can choose whatever strategy you prefer.

> tokio is appropriate for general userspace apps

Yep, and for those I wouldn't recommend it. But tokio is also widely used in performance-critical infrastructure and web services. For those I'd say it can definitely be worth taking a second look at kernel bypass.

When you're at a point of tuning Tokio, consider taking a look at ef_vi/DPDK + SPDK

Your MS-01 routes line-rate 25Gbps in software with VyOS w/o kernel bypass? That's very surprising to me. At what packet sizes?

> "surely if I send request to 5 nodes some of that will land on disk in reasonably near future?"

That would be asynchronous replication. But IIUC the author is instead advocating for a distributed log with synchronous quorum writes.

Is there more detail on the design of the distributed multi-AZ journal? That feels like the meat of the architecture.

As long as your target language has a strict define-before-use rule and no advanced inference is required you will know the types of expressions, and can perform type-based optimizations. You can also do constant folding and (very rudimentary) inlining. But the best optimizations are done on IRs, which you don't have access to in an old-school single pass design. LICM, CSE, GVN, DCE, and all the countless loop opts are not available to you. You'll also spill to memory a lot, because you can't run a decent regalloc in a single pass.

I'm actually a big fan a function-by-function dual-pass compilation. You generate IR from the parser in one pass, and do codegen right after. Most intermediate state is thrown out (including the AST, for non-polymorphic functions) and you move on to the next function. This give you an extremely fast data-oriented baseline compiler with reasonable codegen (much better than something like tcc).