On Tue, Nov 12, 2013 at 10:49 AM, Brendan Eich <bren...@mozilla.com> wrote:
> Mark S. Miller wrote: > >> Much of the early Actors research >> DEC SRC Network Objects >> RMI >> Original-E before I arrived at Electric Communities >> Midori >> Orleans >> AmbientTalk >> Cap'n Proto >> > > Mark (and Tom, cc'ed), please take this as sincere feedback from a fan -- > I mean this in the best possible way: > > I remember the mid-late '80s to '90s RPC wars, Sun RPC vs. Apollo RPC, Ken > Birman et al.'s work at Cornell (and on Wall Street back end systems), > CORBA, Java RMI, all that. I have some scars myself. > > That history, plus some of the names dropped above, form a large > super-counterexample in my opinion. Lessons painfully learned: > > * One cannot ignore network latency and partitioning. > * Sync RPC is the wrong model (it already yielded to async calls, > futures/promises, and the like). > * Weak consistency (I know, people hear "CAP" and give up too much) won, > which surprised some. > * As Mike Stonebraker observes, hardware trade-offs flipped upside down > with a vengeance. > Link please for the Stonebreaker point? On your other bullets, you're preaching to the choir. These are exactly the considerations that led to the E promise design, now adopted by JS. http://www.erights.org/elib/concurrency/semi-transparent.html Where it says "<-", substitute "!". In addition, promise pipelining gives us a huge win over network latency beyond the points made on that page. Now that we've adopted such promises, we've paid the anti-transparency costs of good distributed objects. This was quite intentional. Now that we've paid the costs, we may as well collect the benefits. > > The example of the Web, messy as it is, shows a success story so big that > we live inside it without often being conscious of it, like happy fish in > bubbly water. True, it's still too client/server, too "stateless" with > login and session state built into silos on server networks, too subject to > dreary XSS and CSRF threats. I agree it is not the full distributed system > that it should be. > > But are we really going to build distributed-GC systems at Web scale, with > mutual suspicion and accidental failure accounted for? > > It's as far as I know fair to say that Erlang is used in "mutual trust" > settings, even though "trust" means "assume failure happens, deal with it > as part of the design". So, Erlang is good for systems that distribute > across a server peer-to-peer network, but not yet demonstrated as good for > client/server/p2p/Web in full. Perhaps it or a language/system it inspired > (Go, Rust) will break out across the Web, but this is in the future. > > If we must go once more unto the distributed-GC breach, it would give me > more confidence to see some literature outside the > OCap/RPC/tightly-coupled/research/unshipped-OS > world, which AFAIK has never been demonstrated at anything approaching Web > scale. > > Something built on the Web and even deployed to cite along with the listed > names above would be better. What cowpath could we pave? > > /be > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
