Thank you for your thoughtful reply. Note that you were not accused of jumping the boat; merely that your view is partially biased by subjective economic considerations.

Re. Amdahl, various concerns raised by physical distribution present the proverbial hair in the ointment:

- CAP applies. If the requirement is for a highly-available and highly-consistent system, then scaling up is preferred as we can do away with the 'P' concerns altogether.

- Higher latencies are a given. Realtime distributed e.g. map/reduce algorithms are beyond the reach of most.

- Certain e.g. graph constructs are difficult to partition. A single node compute engine that can scale up may turn out to be the more economically attractive option.

> My belief is that having a highly connected sea of general purpose compute engines, and some additional tools to factor algorithms along their entanglement borders into partial computation fragments will radically change the way things get done.

Right, so we're in agreement here (and I personally love to geek out thinking about that stuff) but with the caveat that such tools do not exist and it is not clear at all that the interface that will be provided to the end-user (read: your average programmer) will remain accessible.

1 - Not everyone can "[think] like a vertex" so Pregel is very nice indeed, but who will be coding for it? Where are these programmers being cranked out and how much will it cost me to hire and retain them?

2 - Not everyone can (afford to) manage a realtime m/r infrastructure (like Facebook). [Oddly enough, there was recently a cry to revolution here by PG regarding the chokehold of "Hollywood" which imho effectively boils down to distribution -- any one can make content these days.]

3 - And a subset of above will not want to trust a 3rd party provider to manage the required infrastructure.

4 - (Subjective) I remain sceptical of the computation efficiencies of the current models which rely on high degree of redundancy and lots and lots of boxes. You must know quite about this (per your HN bio), so I would like hear your thoughts on that. Assume that tomorrow, the cost of running the HVAC and powering up the boxes goes through the roof. What approach to computation will provide the most efficient compute-engine? Let's flip this to physical delivery systems (to highlight the given /fixed cost/ of running a unit-engine) and consider what is more efficient: having a huge number of small cars deliver goods, or using trucks? (You may counter that "well, it is cheaper to train and hire n truck drivers than N mini drivers, but driverless cars will turn that equation upside down". If so, then see 2,3 above.)

In sum:

Not every company is Google/Facebook/Amazon -- with the attendant wealth of capital and human resources of these giants.

Further, not every computation need can be trusted to corporations. Some of us haven't given up on data privacy and insist on it. There are critical "social" applications that need to be written and most certainly Google, Facebook (and may be even) Amazon are not trustworthy enough to host them.

Solving this at the hardware/OS level, imho, will be the more democratic way forward and will take it out of the user/devop land (where it is being addressed at the moment). After all, wasn't that what the PC revolution was all about? We did, after all, already have mainframes and dumb terminals way back when. And this back to the future of cloud and running m/r batch jobs is not democratic at all.

So I am personally rooting for the (future commodity) H/W solution to this problem. Naturally, my 'biases' are clear per above.