<div class="gmail_quote">On Tue, Aug 28, 2012 at 8:56 PM, Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So you get systems that run effectively with less code, less testing,<br>
and less maintenance.<br>
<br>
I'd be curious how many people, based on their experience building<br>
production Erlang systems, would agree or disagree with this.<br></blockquote><div><br></div><div>I believe you're treading dangerous territory here. :-)</div><div><br></div><div>There is less custom code...but such is the case with any framework.</div>
<div>There is less testing ONLY due to less volume of code, which is the case with any framework.</div><div>There is less maintenance due to ... you guessed it, less volume of code.</div><div><br></div><div>So, really, you're looking at "Framework vs Non-Framework."</div>
<div><br></div><div>What "sold me" on erlang originally was:</div><div>1) Distributed was "easy."</div><div>2) Shared-state was built-in</div><div>3) No downtime code deployments</div><div>4) Supervisors</div>
<div><br></div><div>The reality:</div><div>1) Distributed is easy, kinda. Easier. Getting a message to another node is trivial, which is what Erlang does and from then on it's application-level code (eg, you still have to write it and do work. :)</div>
<div><br></div><div>2) Shared state is done via mnesia. House of cards, IMO, having run it. It's just too fragile as-is. One node burps and your whole database goes into a corner, sucking its thumb until you fix it. Ulf's unsplit is a good start, but given current-state I'd have to say it's too risky to run in production for anything without a back-plane network. Split-brain is hard -- may be that wedging Riak in would work here (Ulf's unsplit uses vector-clocks, inspired by Riak.) It would be nice if mnesia at least said "node dead is dead, let the rest run even if the first comes back." We had a 3-node cluster and one node would burp and all three nodes would fail to run. Setting master-node works but then you start going down the "not fully distributed" route. Majority helps ... until a node comes back. If you have 30 nodes and one goes down and comes back...both have node-down states and your whole set of 29 runs to the corner.... Majority + Unsplit + Master is about the best you can get, until your partition falls along Master-lines and when you come back 20+ nodes are all doing copies off the master to sync up. 8-) I really like mnesia...really really, and I really really tried to shoehorn it in. Maybe I'm doing something wrong, but I see similar issues with RabbitMQ's use of mnesia so I don't think I'm too far off. I would love to be shown incorrect here....please? Anyone?</div>
<div> </div><div>3) These are hard. Doable, but you end up with a LOT of testing of the upgrade/downgrade paths. You start questioning the value vs "rolling restarts." It's a golden-hammer when you need it, though you have to really look at the value and "cost" of using such a weapon regularly (testing time vs just rolling restarts.)</div>
<div><br></div><div>4) #winning =:= #winning Love 'em.</div><div><br></div><div>That said, Erlang has become my personal "gold standard" for other languages, and by which I judge all others. :)</div><div>
<br></div><div>-mox</div></div>