[erlang-questions] What do you like the most about Erlang/OTP?

[Maxim Treskin]

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
helpful
4. Code coverage integrated with test frameworks (eunit, common test)
5. Rich processes tracing: messages, function calls with templates, process
related events
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 <moxford@REDACTED> wrote:

> On Tue, Aug 28, 2012 at 8:56 PM, Garrett Smith <g@REDACTED> 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.  :)
>
> -mox
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
Max Treskin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120829/3f9f8970/attachment.htm>