I think this is an excellent primer, and he's an engaging speaker for the most part. But since this is an hour and a half, here's a brief-ish summary:
For 150 years, American wages went up due to labor shortages. This was to induce European workers to move here and take advantage of fertile farmland, slave labor, and easily navigable coasts, and then raised again to keep them from moving West. In the 1970s, wages became flat as productivity increases from computerization and the offshoring of labor became standard business practices, and as more people (women, minorities, Latin American immigrants) became available to the labor market.
However, consumers didn't stop spending. With the invention of credit cards in the 70s, consumer debt rose and has largely kept rising. And since their wages didn't rise, American workers began to put in more hours instead, and we are now one of the most (if not the most) overworked populations in the modern world.
During the 80s, as business balance sheets bulged from flat wages and rising productivity, the executive class started paying themselves vast sums of money, which has raised the average CEO pay from 30-50x their average employe to 350x. Even more ingeniously, all of the money that they should have been paying to their employees was instead borrowed by those employees, creating huge stacks of debt. Hedge funds emerged as a way for the executive class, who literally had so much money that they didn't know what to do with it, began to invest. However, those hedge funds began to make riskier and riskier bets backed with that debt in order to compete for investor dollars. (Editor's note: this was largely made possible by the deregulation of the 90s and the destruction of the firewalls established by Glass-Steagall.)
In 2007, it all fell apart. The working class ran out of credit and couldn't physically work any more hours. Lending completely stopped, even between banks, because every major financial institution was essentially bankrupt. All of the consumer debt assets were worthless. And since this was important, "unlike national health care policy which requires years of careful debate," governments handed over trillions of dollars to float financial institutions through the crisis.
The only problem is that any institution that has actual money has seen world government spending skyrocket, and they are concerned about the government's ability to repay. "Not because the politicians wouldn't pay, because they own the politicians, but concerned that the citizens of the country wouldn't allow it."
So, there are three ways for governments to raise money if they can't borrow it: to print it, which can lead to inflation; to tax it across the board, which loses elections; and the third option is by cutting government spending. (Editor's note: cutting spending is just another form of a tax increase, since those services are probably still a necessity, and the money will now come out of your pocket instead out of the taxes you're already paying.) Governments have chosen the last option.
Now, for a country like America, we're still able to borrow money because our economy is so enormous. But for smaller countries like Greece, who mostly borrowed from foreign banks, they are being forced into austerity by their lenders and by others in the Eurozone. The problem with austerity is that it again is punting the costs further down the road, but instead of just costing paper money, there is a very real chance that foundational damage to the economy will occur. This is because austerity damages infrastructure that is expensive to replace, not only for things like roads and bridges and electrical grids, but for education and social services that create the quality of labor that is required for dynamic and successful economies.
In a nutshell, the power structures in our societies are trying to lay 30 or 40 years of economic planning mistakes squarely on the shoulders of the working class, and it's too much, even according to billionaires like Soros and Buffett.
He then goes on to list what happened in response to the Great Depression: Social Security was created, unemployment compensation was created, and between 1934 and 1941 FDR hired 12 million people since the private sector was unable to do so. And the rest, of course, received employment during the war.
Where did Roosevelt get the money to accomplish all of this? He raised taxes. During his presidency, for every dollar collected in taxes from private citizens, $1.50 was collected in taxes from corporations. Today, every dollar of individual taxes is matched by twenty five cents from corporations. The highest income tax bracket became 94%. (Editor's note: today, effective tax rates for the very wealthy are between 15-20%.)
After Roosevelt was gone, the business community decided to take back what they had given away, and that's pretty much the story since the end of the war.
That gets you to about the hour mark. I recommend watching the rest, if you can't watch the whole thing.
"I suspect that previous attempts haven't been successful for a number of reasons but especially because they tend to be synchronous."
No. Node.js has no special contribution to asynchronicity, which has been in common use for something like 20 years now. Every UI-based program you have ever used is asynchronous-event based, even if it has synchronous components, to say nothing of the many many other Node.js-like libraries that have been written over the past decade in other environments, many with more capable languages that Javascript. None of these have been able to fix RPC, and many of the biggest and most well-funded attempts like CORBA and COM have come from smack in the middle of some of the largest piles of event-based code in the world.
The reason trying to pretend a network transaction is a function call fails has to do with the different semantics of a function call versus a network transaction. Latency differences even when everything is working correctly certainly are a factor, but are really less interesting than the problems of the unreliability of the network and the fact you are crossing a semantic boundary. Every network transaction can fail. Every network transaction might succeed, but with unacceptable levels of latency. Every network transaction might initially succeed but cutoff halfway through, or dribble its results in one byte at a time, or send you a gigabyte unexpectedly, or any of a variety of other failure cases you must at least be ready for, even if you can't "handle" (because in some cases there is no "handling" them). Furthermore, every network transaction incurs a serialization step, in which the semantics of the local program must be re-enforced on the data, possibly with failures thereto. For instance, you might get back JSON that specifies an integer greater than 5 billion in size where your environment is still only 32-bit; no local function call can do that. (Which isn't to say local function calls are therefore perfect, it is just that their failures lie in other places. For instance, your overlarge number got truncated somewhere else in your program, but it wasn't a function call that did it, it was some actual math computation somewhere. The point is that there is a different sort of semantic failure that can occur with an RPC vs a local function call and this inevitably leaks out of any abstraction you could try to wrap around the RPC.) And that was simply one tiny example, not the totality of the issues you can encounter, the vast majority of which are far more subtle than that.
RPC (where "procedure" is an old synonym for function) should by design not deal with these issues if it's really going to be "RPC", because by definition of RPC it really ought to look like a function call. Therefore it must handle all of these issues implicitly, and since no one answer is adequate for all cases, usually incorrectly. You can't seal over network issues anywhere near well enough to make dealing with a network as easy as dealing with a function. You must deal with latency issues, but again, these are ultimately the least interesting aspect. You must be able to deal with serialization and semantic issues; if your language forced you to deal with that on every function call you'd never use it. You must have some way of dealing with the various network failures and even throwing various appropriate exceptions only gets you a subset of the actions you might actually want. You must, inevitably, allow these things to poke through somewhere, at which point your are "configuring" your RPC call, at which point it is really no longer a "procedure call" at all, it's something else.
That it has historically imposed an additional point of synchronous behavior in some cases is because languages up to this point have also been largely synchronous, but that has nothing to do with RPC's far more fundamental failures as a network communication metaphor. It is also the case that if you've absorbed too much Node.js hype that you may underestimate the world's understanding of the problem; take a moment to search for "asynchronous COM", for instance. The first hit I get is an article from April of 2000. The synchronous problem is easily and trivially solved by turning RPC calls into futures objects instead, which has been done, and has not salvaged RPC because it is not the core problem RPC has. And there are other solutions, too, which also don't work.
Regrettably, calling things over a network must be more complicated than a local procedure call; all attempts to make it otherwise have indeed failed to live up to their promises.