[erlang-questions] What do you like the most about Erlang/OTP?
Wed Aug 29 07:42:59 CEST 2012
1. Hot code update
2. WYSIWYG code (© Lev Walkin) — you get exactly desired behaviour of your
code without invasions from dark side
3. Dialyzer — first you don't care about types, then you do; it really
4. Code coverage integrated with test frameworks (eunit, common test)
5. Rich processes tracing: messages, function calls with templates, process
6. Fprof, Eprof
7. Supervisors tree — the best way to organize your code parts in project
and runtime system
On 29 August 2012 12:13, Mike Oxford <> wrote:
> On Tue, Aug 28, 2012 at 8:56 PM, Garrett Smith <> wrote:
>> So you get systems that run effectively with less code, less testing,
>> and less maintenance.
>> I'd be curious how many people, based on their experience building
>> production Erlang systems, would agree or disagree with this.
> I believe you're treading dangerous territory here. :-)
> There is less custom code...but such is the case with any framework.
> There is less testing ONLY due to less volume of code, which is the case
> with any framework.
> There is less maintenance due to ... you guessed it, less volume of code.
> So, really, you're looking at "Framework vs Non-Framework."
> What "sold me" on erlang originally was:
> 1) Distributed was "easy."
> 2) Shared-state was built-in
> 3) No downtime code deployments
> 4) Supervisors
> The reality:
> 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. :)
> 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?
> 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.)
> 4) #winning =:= #winning Love 'em.
> That said, Erlang has become my personal "gold standard" for other
> languages, and by which I judge all others. :)
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions