<div dir="ltr"><div><div>I think, that makes sense. We have to make trade-offs to make a system practical.<br><br>Though, the idea that I was pointing to is that, just like <a href="https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf">FLP proof</a> states that there is no way to know if a process has really failed or the messages are just delayed but Erlang provides a practical and working way to deal with it. Similarly, can a language or standard libraries like OTP give us practical ways to achieve trade-offs among Consistency, Availability and Partition Tolerance? I feel that the same problem (the CAP trade-off) is being solved in each system separately.<br><br></div>As far as I understand, Joe Armstrong, in his thesis, argues that a language can provide constructs to achieve reliability and that's how Erlang came into picture. I wonder whether CAP trade-offs can also be exposed using some standard set of libraries/language.<br><br></div>- Aman<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 19, 2015 at 12:54 AM zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015年12月19日 土曜日 00:42:26 aman mangal wrote:<br>
> Hi everyone,<br>
><br>
> I have been reading a few blogs on Erlang lately and some of them strongly<br>
> points out that Erlang solves the reliability problem very nicely for<br>
> distributed systems. But when I really think about it, Erlang solves only<br>
> half of the reliability problem. It creates duplicate actors, handle their<br>
> crash by linking and supervision but it does not handle the distributed<br>
> state management problem at all. If I go back and look at the thesis of Joe<br>
> Armstrong, it also talks about everything as an actor model. I am wondering<br>
> what assumptions were made about state management at the time of creation<br>
> of the language as well as what are good ways to handle the other half of<br>
> the reliability problem when it comes to Erlang? I understand that this is<br>
> a hard problem to solve but at the same time, it seems to be a generic<br>
> problem for Distributed Systems. Does/can Erlang provide any generic<br>
> solutions?<br>
<br>
Short answer:<br>
<br>
No.<br>
<br>
<br>
tl;dr:<br>
<br>
Three fundamental problems exist: consistency, availability, partition tolerance. Pick two. The Rules forbid solving all three at once.<br>
<br>
<br>
Discussion:<br>
<br>
The problems of distributed data are threefold, and only two can be solved at a time unless you happen to know how to either freeze time, open a wormhole or beat the speed of light. This is why there are no generic solutions to distributed data, only solutions that make tradeoffs of various types, and different tradeoffs are best suited to specific situations -- hence the impossibility of genericizing any solution.<br>
<br>
The basic problem is described in the CAP theorem. It says a system can have:<br>
- Consistency<br>
- Availability<br>
- Partition tolerance<br>
<br>
but that you can only have 2 at once.<br>
<br>
That doesn't mean that all parts of your system have to make the same tradeoff with regard to state management, but again, the fact that a tradeoff must be made is indication that there can never be a truly generic solution to this.<br>
<br>
What Erlang lets you do is decide *for sure* whether something is running or crashing, instead of handling random faults in ad hoc ways. Tolerance for distributed failures is *also* something Erlang leaves up to the programmer to figure out, because the same CAP problem that exists in distributed state management also applied to the system's view of the state of its own operational capacity. (Does every node know what the state of every other node? That's data, too!)<br>
<br>
So this is a hard problem. In the real world *most* systems seem to be designed to start involving humans once partitions occur (though most have the ability to run in a degraded state of service until a sysop fixes things). In the imaginary world where there is a software package to cure every ill, all our theories are correct, software is bug-free and network latency is zero this is handled automatically by correct implementations of logically flawless leader election algorithms that always work and a second partition never occurs in the middle of partition resolution. But we don't live in that world.<br>
<br>
Partition tolerance is a hard problem, maybe the hardest to code around, so most systems seem to make a tradeoff that sacrifices (some level of) partition tolerance in exchange for (general, but maybe deferred) consistency and (an absolutely insane focus on) availability.<br>
<br>
-Craig<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>