[rramadass]

>Here we're starting to sound like we're duplicating a mini Operating System inside a language

In case you didn't know, Joe Armstrong actually calls Erlang/OTP an "Application Operating System(AOS)" in his thesis paper.

That is the entire point of that language's design.

[peter_d_sherman]

I did not know that! Interesting! I will have to check out Joe Armstrong's paper...

[rramadass]

The discussion in this thread is actually missing the forest for the trees and probably giving a wrong impression of Erlang for people new to it.

Erlang is always spelled as Erlang/OTP (i.e. language/patterns of components provided in libraries) + Erlang Run Time System(ERTS) (the BEAM VM + support components). The whole "System" is what makes it so powerful and uniform with a single environment. Every single "feature" exists only in the context of the whole and cannot be discussed in isolation (See https://blog.stenmans.org/theBeamBook/#_layers_in_the_execut... for a graphic).

Compared to the babel/hodge-podge of languages/tools/frameworks used to duct-tape current-day distributed apps, Erlang/OTP is a godsend. It is purely an accident of fate that it never became mainstream for distributed Web programming for which it is eminently suited for. Imagine Erlang running in the Browser frontend and also on the Server backend. Everything would be uniform and clean and one would have a robust distributed system with all parameters taken care of by the "System" itself; we would just need to focus on the "business logic" and be done with "app development".

[peter_d_sherman]

>Imagine Erlang running in the Browser frontend and also on the Server backend. Everything would be uniform and clean and one would have a robust distributed system with all parameters taken care of by the "System" itself; [...]

That is a very compelling idea -- the idea of a language which supports concurrency natively -- such that a given source code base could be split up into "client" (web browser) and "server" (web server) components (and/or source code) easily, ideally automatically...

I think that is a very compelling idea, indeed!

This language might indeed be Erlang/OTP + Erlang(ERTS) + BEAM VM -- but it could conceivably be another language -- if that language was designed with the appropriate concurrency in mind: (https://en.wikipedia.org/wiki/List_of_concurrent_and_paralle...)

But that being said, Erlang/OTP+ERTS+BEAM VM -- definitely looks like it is worth further exploration!