I am wondering what you guys like the most about Erlang/OTP, especially
newcomers, maybe it changed your life, allowed you to climb the Everest
(or at least sleep at night).

I'll be synthesizing that into a few key points that I am hopeful will
be reusable by anyone wanting to sell Erlang to their friends/work/clients.

So help me by telling us what's so good about it!

Thanks.

You can send arbitrary messages to arbitraty processes, call arbitraty
functions, restart anything by hand. This gives utmost flexibility to
inspect and fix a running system.

$ erl -setcookie company_name -sname d

You can send arbitrary messages to arbitraty processes, call arbitraty
functions, restart anything by hand. This gives utmost flexibility to
inspect and fix a running system.

$ erl -setcookie company_name -sname d

Sent from my iPhone

On 28.08.2012, at 0:53, "Motiejus Jakštys" <desired....@gmail.com> wrote:

A few years later: links & monitors, ability to effortlessly combine many
processing stacks into single solution without silly interferences.

Hard to list just a handful of properties though, it all fits together so
nicely.

We are in a new phase of expansion, and we are hiring more
erlang devs to work on a distributed system.

Please get in touch with me, if you are interested.

Xiaopong

I liked the fact that erlang was an "old" language --- not "flavour of the month" or "new kid on the block". Erlang had matured for so long quietly --- like good wine or cheese.  This helped my client of the time go with erlang too --- the huge projects that erlang had been used for.

Line-by-line erlang can feel difficult and slow to work with, but when you look back at what you've created (and consider how you might have created that in Your Other Favourite Language), you realise erlang is a very helpful language.

I like the fact that "behaviour" is spelt properly.

Ivan

--
hilaritas excessum habere nequit.

On 27 Aug 2012, at 21:34, Loïc Hoguin <es...@ninenines.eu> wrote:

* Inconsistencies/Missing functionality in the standard library:
   - The principle of least surprise does not apply
   - proplists:get_value(foo,[]) returns undefined
     orrdict:fetch(foo, []) throws and error.
     There are plenty of examples where similar operations in different
     modules either throw or just return undefined but never in a
     predictable way
     My favorite: calling split on a one element list throws an error
   - functions operating on lists sometimes expect the list as first
     argument, sometimes as the last argument
   - merge, explode, implode, traversing, filter, search for
     dictionaries would be nice
   - missing json parser
   - crappy http support! Its the 21st century and the web is a major
     thing by now and people want to build awesome backends with erlang
     but in terms of http erlang really is a ghetto. the supplied client
     and server modules fail at the slightest traffic blow
   - calender implementation is super weak and is missing a lot of
     functionality which I see people implementing over and over again
   - there are sooo soo many things that you could improve about the
     standard library its actually kind of sad.

* OTP Releases: for most of the use cases other than big telcos or
   banks this is far more confusing then helpful especially when
   beginning erlang. While I'm sure there are valid use cases for it
   most of the time I thought it was bloated, cumbersome, slow and error
   prone.

* No built in support / standard way for installing libraries - instead
   people have to find out about rebar themselves. Look at
   http://rubygems.org in contrast or
   https://www.ruby-toolbox.com/categories

* Lack of namespaces (duck and cover) - Actually I'd be more than happy
   with a ruby / python way of doing it but I guess that won't happen

* I also think the supplied test libraries are not that great to get
   started or to motivate anybody to test from day one

* Error messages are often not helpful. BadMatch etc could include more
   context information to spot the errors faster

There are a lot of things I like and even love about Erlang but these
are the ones that constantly annoy me.

I'll answer a few points anyway.

(I'm not going to go into the debate of "included by default" vs
otherwise, I'm a big proponent of a tiny OTP distribution and letting
people choose what to use. So I wouldn't want a JSON parser by default.)

I overheard things about rebar getting in the OTP distribution, though.

The only thing missing is a central repository for listing available
application and libraries.

something_test() ->
     true = something(123).

It can't get any easier. And I'm not even talking about the greatness of
ct and proper...

DBM

On Aug 28, 2012, at 4:28 PM, David Mercer wrote:

Regards,
Zabrane

Cheers,

DBM

Regards,
Zabrane

Cheers,
___
  /orben

On 2012-08-27 22:34, Loïc Hoguin wrote:

1. Understandability

I don't mean 'readability'. I strongly believed the two concepts are
somewhat exclusive. Poetry can be beautiful and fun to read, while not
being able to understand the underlying meaning.

Erlang, through OTP, allows to break down application in quickly
understandable parts. I can pick many OTP projects (given they're broken
in OTP apps), check at the dependencies, and figure out what is the top
level, what is lower-level, and break all the fragments individually
into something manageable, that I can hold in my head.

This does mean easier maintainability, because pretty much all aspects
of maintenance have 'understanding the code base' as a prerequisite. The
easier things are to figure out, the better I am.

2. Growing a System

Through Fault tolerance and OTP apps allows me to keep a system
functional even when imperfect or buggy. This is great because none of
the software I write will be bug free, nor satisfactory to the customer
in the first few iterations.

Being able to do hot code loading, shut down or restart only part of a
node (due to OTP apps) during a deployment, inspect it while it runs,
connect to various nodes, etc. is all awesome. And everything works with
or without GUIs so I can check anything even from my smartphones, away
from home, if things go wrong.

Overall I see it as a very good environment from a devops perspective.

On 12-08-27 4:34 PM, Loïc Hoguin wrote:

I believe that Erlang's key differentiator, which people should look
closely at is this:

- Fine grained process isolation

The motivation for the design was to build systems that can survive faults.

As a pragmatic functional language, Erlang lets you build such systems cheaply.

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.

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.  :)

So far I've been able to put all these things into 6 key categories.
This is obviously not fully done but I'd like to hear your thoughts on
it. If you have anything to add you're welcome too! Categorization might
not be the best either.

Write less, better code
* Pattern matching
* Bit syntax
* Simple base language
* DSLs
* Only worry about success cases (links to crash and fault tolerance)

Fault tolerant concurrency by design
* Erlang models the real world
* Lightweight processes
* Fine-grained process isolation
* Shared nothing messaging, messages processed in the order we want
* Crash early, crash often (catch errors where they happen)

A better OS for your applications
* OTP
* A system as a collection of small separate components
* Understandability and maintainability
* Upgrade without the need for restarting
* Numerous ways to inspect, debug and trace running nodes
* Combine many stacks without interference

Distributed
* Easy to setup, easy to manage
* Same code for talking to a local or a remote process

Community
* Nice, welcoming people
* Modest people, no drama queen
* Experts willing to share their knowledge

Mature
* Code unlikely to break in future versions
* Sound design principles for building robust systems (OTP)
* Numerous testing tools
* Property-based testing