It is different because it is assembled from manageable pieces and still enjoys the benefits of memory separation.
For example, running a tiny jobs server:
* Scheduler in one process which spawns
* Application code running in many subprocesses
The scheduler might be in Ruby and the jobs might be in Ruby; or the scheduler might be Cron and the jobs in shell. In either case, if a job crashes the other jobs and the scheduler are very likely to carry on their work.
It is also nice that you can bring together tools from different communities into a single application. A "Rails" container might utilize Nginx (C), Rails/Unicorn (Ruby) and Node (JS/C++) together. A single statically linked application would, barring some really amazing innovations in something like Clang modules, have to be in one language therefore from one community.
> A single statically linked application would, barring some really amazing innovations in something like Clang modules, have to be in one language therefore from one community.
Not necessarily. If they all can compile to native machine code with the same C-like semantics, they can (in theory) be combined in that sort of manner. This is true of both Rust and Go, last I checked, as it is with pretty much any compiled language that has a "convert to C" step (Chicken Scheme is an example that I'm particularly familiar with) or perhaps even a "convert to LLVM IR" step.
Not that this is especially feasible for the majority of languages being used in web development (at least by those with a lick of sanity; Go and Scheme are the only exceptions that I'm aware of off the top of my head), but it's still worth considering.
Last I used Go (granted, 2010), it refused to use the platform ABI, and shipped with kenc so that you could compile your C code for its ABI. So, it had C interop, but not binary interop with C. For the kind of interoperability you're talking about here, if each language uses its own ABI, we get O(N*N) complexity. Have things changed with the Go ABI, or at least its FFI?
I'm sure the Plan9 ABI variant used by Go makes more sense than the platform ABI, but supporting the platform ABI for FFI doesn't add much complexity at all to the compiler.
In that case, I stand corrected with Go (I incorrectly assumed that - being supposedly a systems language - it would support the platform ABI, but I guess Go is even worse than I thought ;) ).
I'm 91% sure my point still stands with Rust, though, at the very least if everything's compiled through LLVM (and uses the same calling conventions).
Erlang solved a lot of problems of scale in very effective ways. These new architectures are solving the same problems in ways that look similar from a distance. This new(ish) approach just means we can use existing software mostly unchanged, while still getting a lot of the resiliency benefits of something like Erlang; doing it with Erlang means everything has to be written in Erlang. That wouldn't be a crazy idea for some deployments. But, for others, it's not tenable.
Erlang's support for C modules was always good, though. PyPy, Swift and Rust do all seem to have a fairly good export-to-C story. With Clang modules something like Erlang could become the "cloud shell".
For example, running a tiny jobs server:
* Scheduler in one process which spawns
* Application code running in many subprocesses
The scheduler might be in Ruby and the jobs might be in Ruby; or the scheduler might be Cron and the jobs in shell. In either case, if a job crashes the other jobs and the scheduler are very likely to carry on their work.
It is also nice that you can bring together tools from different communities into a single application. A "Rails" container might utilize Nginx (C), Rails/Unicorn (Ruby) and Node (JS/C++) together. A single statically linked application would, barring some really amazing innovations in something like Clang modules, have to be in one language therefore from one community.