[jlouis]

Hmm, thinking some more on this, this holds locally in Erlang, but not in the distributed communication. If we have m1: A1 -> A2, m2: A1 -> A3 and then in m3: A3 -> A2, then the message ordering will always be that m1 comes before m3 in A2 (locally).

Locally, a message pass never fails and always delivers the message directly. It can't be in-flight, so m1 is placed in the mailbox before m2 happens, and thus m3 will always come later.

In the distributed setting, A1, A2 and A3 might be living on three different nodes, and then m1 might get delayed on the TCP socket while m2 and m3 goes through quickly. Thus we observe the reverse ordering, m3 followed by m1. This is probably why the causal ordering constraint is dropped in Erlang. Is pony distributed?

[n3otec]

not yet, but it will be soon, and with the same causality guarantee

[lostcolony]

Isn't that going to kill performance (and possibly even kill the system, in the event of partial netsplits or similar)?

[e12e]

That sounds... interesting. So if A1 is on a different segment, but has a faster link (less congestion?) to A3, than A2, even if it takes 1000t time to send the first message from A1 to A2, and only 10t+t time = 11t time to send a message, from A1 to A3, and from A3 to A2 -- the plan is to guarantee ordering of messages m1, m3 at A2 (delaying m1 at least 989t)?

[saryant]

How will Pony achieve this in a distributed context? Isn't this essentially asking for exactly-once delivery?

[jlouis]

How do you intend to achieve this?