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

[Loïc Hoguin]

Hello,

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.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Motiejus Jakštys]

On Mon, Aug 27, 2012 at 10:34 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
> Hello,
>
> 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).
>

Hi,
killer feature for me is possibilities to interact with running system.

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
> net_kernel:connect_node(db@p1).
true
> rpc:call(db@p1, yodadb, how_are_you, []).
{still_alive, [some, stuff], but_soon_will_die, [why]}. ...

--
Motiejus Jakštys

[Motiejus Jakštys]

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

> Hello,
>
> 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).
>

Hi,

killer feature for me is possibilities to interact with running system.

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
> net_kernel:connect_node(db@p1).
true
> rpc:call(db@p1, yodadb, how_are_you, []).
{still_alive, [some, stuff], but_soon_will_die, [why]}. ...

--
Motiejus Jakštys

[Max Bourinov]

Hot code update. This is super cool.

Sent from my iPhone

[Max Lapshin]

Simplicity together with performance and rock solid code from the very
first line of code.

[fr...@circlewave.net]

On Mon, Aug 27, 2012 at 10:34:38PM +0200, Lo?c Hoguin wrote:
> 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).

As newcomer: pattern matching and super-simple base language.

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.

BR,
-- Jachym

[chan sisowath]

as a newcomer,

learn cool stuff, base code for a given project is small compare to other language,

then you can dig in easely to learn.

 so plaisant to do stuff you never could imagine 

to do in language like PHP or java without pain

and also programming in erlang is more fun than before.

the main probleme, there are few position in erlang programming ;).

2012/8/27 Loïc Hoguin <es...@ninenines.eu>

[chan sisowath]

erlang itself

2012/8/28 chan sisowath <chan.s...@gmail.com>

[Xiaopong Tran]

On 08/28/2012 06:17 AM, chan sisowath wrote:
> as a newcomer,
>
> learn cool stuff, base code for a given project is small compare to
> other language,
> then you can dig in easely to learn.
> so plaisant to do stuff you never could imagine
> to do in language like PHP or java without pain
> and also programming in erlang is more fun than before.
>
> the main probleme, there are few position in erlang programming ;).
>

Not to hijack the discussion topic, we still have 4 to 5
erlang openings in Shanghai to fill :)

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

[Ivan Uemlianin]

I loved the ease of working with binary data. Using that for the first time was "laugh out loud".

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.

[John-Paul Bader]

I think the question would be more interesting the other way around.
What do you not like about Erlang/OTP. Here is my list:

* 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.



~ John

[Loïc Hoguin]

On 08/28/2012 03:07 PM, John-Paul Bader wrote:
> I think the question would be more interesting the other way around.
> What do you not like about Erlang/OTP. Here is my list:

Unfortunately that doesn't help me!

I'll answer a few points anyway.

> - missing json parser

You are kidding, right? There's at least 10 of them available.

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

> - 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

Again there's a lot more available than what's in the OTP distribution.

> - there are sooo soo many things that you could improve about the
> standard library its actually kind of sad.

Send patches and become happy.

> * 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.

rebar makes them really easy. They're much easier to build and deploy
than custom solutions.

> * 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

That's because the common way of doing things doesn't go through library
installation. Instead you get the source and build a release out of it.

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.

> * 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

Hopefully it'll never happen.

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

Are you kidding? Erlang has the most wonderful test libraries ever. Want
to test that something(123) returns true? Include the eunit file and write:

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

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

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[David Mercer]

On Tuesday, August 28, 2012, Loïc Hoguin wrote:

> rebar makes them really easy. They're much easier to build and deploy
> than custom solutions.

Rebar doesn’t work on all the platforms Erlang works on, so it is not a
general solution.

DBM

[Zabrane Mickael]

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

> On Tuesday, August 28, 2012, Loïc Hoguin wrote:
>
>> rebar makes them really easy. They're much easier to build and deploy
>> than custom solutions.
>
> Rebar doesn’t work on all the platforms Erlang works on, so it is not a
> general solution.

But a correctly written Makefile does (even on Windows).

Regards,
Zabrane

[David Mercer]

On Tuesday, August 28, 2012, Zabrane Mickael wrote:

> > Rebar doesn’t work on all the platforms Erlang works on, so it is not
> a
> > general solution.
>
> But a correctly written Makefile does (even on Windows).

Yep, that's what I use, for exactly that reason. Except that Makefile's
have different syntax due to different directory delimiters, unless you
compile under Cygwin. I forget why I can't use Erlang's emake. Anyone use
that successfully? Anyone know why I don't?

Cheers,

DBM

[Zabrane Mickael]

>> But a correctly written Makefile does (even on Windows).
>
> Yep, that's what I use, for exactly that reason. Except that Makefile's
> have different syntax due to different directory delimiters, unless you
> compile under Cygwin. I forget why I can't use Erlang's emake. Anyone use
> that successfully? Anyone know why I don't?

We're using Makefile + Emakefile with "mingw" without any problem.

Regards,
Zabrane

[Loïc Hoguin]

On 08/28/2012 04:28 PM, David Mercer wrote:
> On Tuesday, August 28, 2012, Loïc Hoguin wrote:
>
>> rebar makes them really easy. They're much easier to build and deploy
>> than custom solutions.
>
> Rebar doesn’t work on all the platforms Erlang works on, so it is not a
> general solution.

You can still use rebar to generate all the files and then tweak as needed.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Torben Hoffmann]

http://musings-of-an-erlang-priest.blogspot.com/2012/06/why-love-erlang.html

Cheers,
___
/orben

On 2012-08-27 22:34, Loïc Hoguin wrote:
> Hello,
>
> 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.
>

--

http://www.linkedin.com/in/torbenhoffmann

[Steve Davis]

Cheap process spawning (which is transformative)

Pattern matching (especially with binary pattern matching)

[Fred Hebert]

That's a tough one, because I want to avoid the general "processes! they
good!"

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:
> Hello,
>
> 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.
>

[Garrett Smith]

On Mon, Aug 27, 2012 at 3:34 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
> Hello,
>
> 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.

You know of course this is a topic of great interest for me :)

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.

Garrett

[Mike Oxford]

On Tue, Aug 28, 2012 at 8:56 PM, Garrett Smith <g...@rre.tt> 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

[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

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--
Max Treskin

[Erik Søe Sørensen]

One thing I've found useful is the ease of having small embedded DSLs -- data-driven code, also known as. Writing small interpreters can do wonders sometimes, and is easy in Erlang.
Here @work we used that for a project were we needed a set of heuristics-based data transformation - "if the data has this form, apply that transformation". And I've also written data-driven unit tests.
Erlang's literals are fairly good for this.
The generators of QuickCheck and its kin are another example of this.

(Erlang's far from unique wrt this, but it's a thing to like nonetheless. Scala and Haskell are stronger at DSLs in some respects, I believe -- but I don't think they have something like file:consult/1.)

And, as others have mentioned: good, strong encapsulation, in the form of immutable values and process-level isolation - encourages separation of concerns, increasing the chance of understandable code.

2012/8/27 Loïc Hoguin <es...@ninenines.eu>

[Loïc Hoguin]

Thanks to everyone for helping.

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

[Max Lapshin]

What are people talking about, when they say, that erlang have DSL?

Erlang lacks any metaprogramming (parse_transform is not an example of
good metaprogramming =).

[Joe Armstrong]

term_to_binary and binary_to_term

It's incredibly useful to just flip backwards and forwards between
internal and external
representation of terms. Databases which can store *anything* sending
*anything* over a socket
encrypting *anything* become one-liners

receive
F -> F()
end

/Joe

On Mon, Aug 27, 2012 at 10:34 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
> Hello,
>
> 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.
>

> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu

[Paul Barry]

For me, it's the way Erlang makes me think about what I'm trying to do
with my code. I find I'm thinking more, understanding more, and
coding better.

--
Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul....@itcarlow.ie
Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland.

[Evan Miller]

One thing that hasn't been mentioned is "hackability": everything is a
term, so it's easy to inspect and alter other people's "opaque" data
structures even without a documented API.

--
Evan Miller
http://www.evanmiller.org/

[Robert Virding]

----- Original Message -----
> From: "John-Paul Bader" <hu...@berlin.ccc.de>
> To: "erlang-questions" <erlang-q...@erlang.org>
>
> orrdict:fetch(foo, []) throws and error.

This was done on purpose, there is a 'find' which returns whether it was there and a 'fetch' which assumes that it is there.

> 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

But you are right here.

Robert