I don't know the answers with that much more clarity than you. I'm proposing to change the cost structure completely and I'm making a lot of guesses about which costs and which savings will cancel each other out and to what degree. I don't think there actually is anyone out there who knows what the result of this experiment will be once it meets the mess of the real world. I do think I have a bit of free-lunch factor going for me though in all the layers of complexity that are just not present in my implementation. I certainly don't expect to have to do latency hacking with optimistic updates. I am a UI engineer originally so my approach is more like "make it feel fast" than "give it super-high throughput". In UI we know that something that produces some results incrementally feels much faster than something that can only produce all its results at the end, in part because you can start doing something with the results immediately. Wall clock time can be saved sometimes even at the expense of greater use of CPU time. To make use of that trick though you need to be able to describe the system when it's in a state of partial evaluation, and that's the trick we have up our sleeve generally. If we have a complex computation do to, say something to do with the type graph, then we would want to show you the state of the recomputations as they propagate outwards from your changes.