Mach 3.0 was the kernel used in NeXT and the original Mac OS X release. It was quite a bit later replaced with a rewritten kernel XNU, that’s basically a hybrid. The reason as I understand it, message passing in the kernel is expensive when crossing user space so often.
I wouldn’t call that nothing coming of Mach, it did really well!
Also, I’d say that micro-kernels are closer to the paradigm of react/redux (redux the message bus, react the user space servers) than to a monolith design like Linux.
I remember where I was and what I was supposed to be doing when I was instead reading the HN article that posted this lwn article (above) about Magenta 2 yrs ago, after finding Eric Love's Guide to Linux Kernel Development, and found this a fascinating read to compare to, given my learnings in kernel dev at the time.
https://en.wikipedia.org/wiki/Redux_(JavaScript_library)
https://en.wikipedia.org/wiki/React_(JavaScript_library)
Perhaps you're talking about the Flux architecture? Not the same thing. Care to share the video you mentioned?
Redux and Flow are somehow branded as alternatives to MVC, when they are precisely MVC (store=model, dispatcher/reducer=controller, etc). It seems that Facebook (and many others) implemented MVC very poorly and pretended to abandon it instead of admitting they just did it better on the next attempt.
If anything, the success of redux simply reinforces the fact that MVC is a very useful pattern for UI applications. But, it bothers me that newer developers might be persuaded by the anti-MVC branding.
A key design feature of Flux is that many unrelated (or related) stores can respond an event, and that there is a defined lifecycle for handling events. I don't believe those really map to MVC.
What I found interesting was that the original developer(s) of react.js seems a lot more up-front about this:
https://omny.fm/shows/future-of-coding/1-1-how-reactjs-was-c...
Of course, the whole idea of, in-theory, re-creating the UI at every refresh cycle is not part of MVC, so that is new and interesting. Considering all the work that has to be done to undo that abstraction (as it doesn't really match reality), I am not sure how useful it actually is.
https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
Because Mach. First generation microkernel. Slow. The microkernel world has moved way past that, whereas Hurd has stayed behind still using Mach. [0]
The second generation was spawned by Liedtke's L4, which basically attacks the performance problem of the first generation, making it negligible.
The third generation makes capabilities a first class citizen, core to the design. Its main representative is seL4.
As an added note, multiserver is a better fit for SMP than locks and the lock contention they imply.
[0] http://sigops.org/s/conferences/sosp/2013/papers/p133-elphin...
Redux came first and it happened because the "interaction graph" between various components on the website became virtually impossible to resolve cognitively. The engineers (especially on-boarding engineers) faced troubles understanding how everything worked in concert and, especially, the side-effects of a single change. The nail in the coffin for the engineer was Facebook chat and she was forced to use numbers, instead of lines, to depict interactions because the graph was too dense. Redux forced interaction in one direction, with "back interaction" happening one frame/tick later. Web developers have praised and embraced this architecture.
If you look at the very first image in the article, it moves from a very straightforward application -> VFS -> ext2 -> driver -> disk graph to a [potential] rats nest. It runs counter to the hard lessons that Facebook have learned with complex distributed systems.
Is this why nothing has really come from Mach/Hurd? Up until putting 1 and 1 together a few minutes ago, micro-kernels sounded so clean and elegant. They now seem unwieldy. Perhaps there is exists another layer of architecture that can tame the dependency/interaction graph; isolation really does sound like a good idea, but we need a better way of doing it.