Mu: the movie

great overview!

I've uploaded it to the Internet Archive: https://archive.org/details/akkartik-2min-2020-04-20. Thanks for the suggestion! It was surprisingly painless, and I had no idea it was possible. I always assumed IA was like a museum that it was a privilege to be in the collections of.

This slays.

Ha, I figured I'd talked about goals enough in this group. I think mainstream software is stuck in a vicious cycle of abstractions breeding more abstractions, ratcheting up ever-increasing complexity in the process. I want to switch to a virtuous cycle where using tools gradually gets you to learn about their internals, empowering you to periodically strip out complexity you don't need/use. Doesn't have to be everyone, but hopefully we can move to a fanout of thousands of people per fork rather than millions of people per fork of popular software. Concretely, on Mu: * Source is always present. If you make a change it's automatically recompiled next time it's used. * You can run any command to emit a trace, and then browse the trace right there at the commandline to audit what it did. The trace browser was actually the #1 thing I wanted to demo, but I had to cut it because the current UX is so bad it's impossible to make sense of what's going on if it's not interactive.

Yes you have talked about this and, sorry, I should have been more specific. Do you have a plan for getting people to adopt this project and build things on it? Or is it meant to demonstrate possibility (in the style of Bret Victor, say)? Are you taking an "If you build it, they will come" approach? Are you building it just for yourself at this point, with no need for external validation? As an example, I'm building Hest for my coworkers, so that they can more easily draw and code the simulations that my company sells. They know I'm building it for them, and they're participating in the dev process. That's the short term goal. Then, we have some clients that would like to build their own simulations, so I'm designing Hest with that longer-term goal in mind. Then there's the side goals — I'd like Hest to be a tool I can use for live-coding music, playing with algorithms, visualizing data, etc., if it ends up being any good at those things.

Ah, got it. I definitely want this to be real and not just a demo. Something I use and eventually do all my development on. Goal is to find 20-200 people to join me. Validation = are people gradually hacking on and forking it, even if only for tiny tweaks? It's like a long-term longitudinal study. Overly rapid adoption might be a net negative.

I think you mentioned testing being a central part of your project, how is it central/different? does it involve the traces you mentioned above?

Yeah, Mu does tests differently in a couple of ways: * Dependency injection for syscalls means that the conventional wisdom of testing business logic rather than I/O no longer applies to Mu. * White-box testing using traces allows us to test implementation properties (speed, deadlock freedom, fault tolerance, etc.) in addition to just functional results. * Writing most tests in terms of traces will permit radical reorganizations of the computing stack without needing to update a bazillion tests. Probably the best place to read more about this is the first couple of screens in the previous prototype: https://github.com/akkartik/mu1#readme. I don't have a good demo for this stuff yet in the current version.

Awesome! Seeing the kernal packaging, it looks like a lot of code wouldn't have had to be included. Do you see a future where it could include only the parts necessary for your code?

I really like the ideas of DI for syscalls and testing traces

Thanks both! @Leonard Pauli yeah the kernel is coming from a personal fork, and I've spent some time stripping out code from it. Went from 27M to 12M LoC. But I don't really know what I'm doing. Still haven't made use of the network stack or frame buffer. I've also experimented with a hobbyist OS that is just 33k LoC of C++. That seems more tractable. But the OS side has been on hold for a while as I wrap up the language. Couple more months, I think.

Great inspiring demo! It makes pop up lots of ideas and questions. Some have already been discussed in the thread.

I don't know enough about WebAssembly, unfortunately. My biggest reservation at the moment: you need a web browser to run it. (Is that even true?) And web browsers are basically the anti-Mu given how complex and specialized and all-consuming they've become. But if we had/have a parsimonious abstract platform for WebAssembly -- why not? (But then, why is WebAssembly special? I don't know enough to answer that question.) The Mu I've built is just one possible instantiation of many possible stacks. (If x86 is good enough, probably anything is.) The basic ideas are to start with your computational substrate and "go with the grain of it", getting to something ergonomic as directly as possible. It's quite likely you can perform this "transform" starting from any substrate. But to call this "emitting" is to look at it from the wrong direction. What we do is to keep the substrate fixed and pick the simplest possible notation that's easiest to translate to this substrate. So Mu atop x86 would look very different from Mu atop WebAssembly. There's been some past interest in a RISC-V version of Mu, and I'm super supportive. I hadn't considered WebAssembly, but if someone wants to run with it I'd again love to contribute to it.

wasm runs outside the browser, here's a project for it: https://wasmer.io/ and more related to mu: https://wasi.dev/

You can see WebAssembly, as web first technology that is interesting enough that it is seen useful outside the web platform. So, like Mariano points it, there are WASI initiative and all the WebAssembly runners (like wasmer) that allow you to take a WebAssembly binary and execute on any computer. Some people have even try to build some WebAssembly unikernerls.

Gary Bernhardt's "The Birth & Death of JavaScript" continues to come true. Love it.