[fmontesi]

Right, excellent question. We should put something in the FAQ. It's going to take some time to answer properly, but here are some initial pointers. Note that while I know Erlang academically I am definitely not an expert, so feel free to add more comments if you like.

Both languages are based on message passing, but Erlang is functional whereas Jolie is classical imperative/stateful.

Jolie provides architectural programming, e.g., you can make proxies abstracting from the behaviour of what you are composing with a language primitive.

Jolie provides integration natively, e.g., with automatic data transformations between different data protocols. The contract with the developer is that if you need to change protocols or deployment information (e.g., switch from TCP/IP to Bluetooth L2CAP or in-memory communication), you just have to change a couple of lines in the deployment part of a Jolie program and the rest will continue working without modifications to the program logic (logic/deployment decoupling).

Jolie has dynamic fault handling: fault handlers can be updated at runtime compositionally (higher-order code composition), which is afaik a new thing.

[fmontesi]

Another thing: the fact that it is imperative does not mean that we suffer from all the side effects. You cannot share data among different microservices, you must use communications (if you need performance, communications can be in-memory). The imperative paradigm (mixed with workflow programming) is used only for internal state manipulation, so that it is safer for concurrent programming.

I should really get down to write all of this in the FAQ page.. ;)

[jlouis]

None of those concepts seem unique to Jolie compared to Erlang, but I have yet to understand the concepts of Jolie well enough to figure out if something is conceptually different.

Architectural programming: gen_server is a fine example.

Integration: Erlang is opinionated but as soon as you have a lens to erlang terms, everything is easy. This is the point where Jolie may have an advantage.

Dynamic fault handling is subsumed by dynamic code loading.

[fmontesi]

I would be very interested in seeing a comparison with gen_server, it looks interesting.

Embedding in Jolie looks like a language primitive implementing something that resembles some of the ideas found in supervision trees.

AFAIK, dynamic fault handling is not subsumed by dynamic code loading in the specific case of request-response operations in parallel code (http://iospress.metapress.com/content/p0647559l8455778/?issu..., see my webpage fabriziomontesi.com/research.html for the pdf), but if that's relevant for the comparison with Erlang, I don't know. In all other cases your statement is correct. It's subsumed also in that case if you allow for dynamic code loading in the middle of waiting for a response for a request in a request-response invocation.

Another point which may be interesting: in Jolie a process inside of a microservice can have many input queues. Which messages go in which queue is decided by (an easier form of) correlation sets, basically a declarative part of the program where the programmer tells which parts of messages identify the queue in which they must go. These can be application data or even HTTP cookies, we use this features a lot for integration.

[fmontesi]

It looks like another interesting difference may come from the workflow primitives (e.g., sequence, parallel, input choice) that Jolie comes with.