
When would you choose Erlang? (2013) - rubyn00bie
http://blog.troutwine.us/2013/07/10/choose_erlang.html
======
ffn
>Erlang is not good for Glue-together style web application

Granted Elixir's Phoenix framework is not Rails level yet, it's system of
plugs and heavy inspiration from rails actually makes it quite useable as a
replacement for rails. Also immutability and the associated smaller memory
footprint makes it more feasible to run cheaply on services like heroku or
aws. Personally, I think elixir is a good boat to jump on to carry us over to
the next world of web development.

~~~
troutwine
I wrote this article way back in 2013. Initial commit of Phoenix was Jan 18,
2014.

But! you're quite right. Elixir is focusing on the web application type things
that Erlang and the community around it has never much addressed. There's
enough interoperability from Elixir to Erlang that you could probably say the
ecosystem as a whole is addressing the problem if you squint hard enough.

Side comment, it's been interesting to see Elixir grow since 2013. A lot of
folks learn Elixir and then Erlang but I think it's less common to learn
Erlang and then learn Elixir. It's led to an interesting situation where
Elixir has had to bootstrap knowledge about OTP on its own terms without a
large pool of domain experts sitting around. The asymmetry in knowledge--
knowing Erlang does not imply knowing Elixir but knowing Elixir implies
knowing Erlang--also makes me wonder how the squinting assumption above will
shake out long-term. ¯\\_(シ)_/¯

~~~
phamilton
As someone who has gone from Ruby -> Erlang -> Elixir, I'm both thrilled and
terrified by the culture developing.

On one hand, you have a very similar open source culture to what exists in
Ruby. The fact that hex.pm exists alone is amazing. Libraries are expected to
work, be documented, and be maintained.

On the other hand, the number of questions that can be answered with RTFM is
astoundingly high. Where Erlang has an implicit knowledge requirement
regarding OTP and distributed systems in general, Elixir has a much lower
barrier to entry in the community.

An Example: On one of my libraries (a db driver) I have received multiple
requests for "Add section to README on how to use this with Phoenix". I have a
section on how to add to a supervision tree, which from the erlang world is
overkill, and I expect users to be able to connect the dots.

That said, the core team is pretty dang smart. There's plenty of OTP wisdom
there, and they aren't very quick to give into the mob rule of the community.
It's under strong guidance.

~~~
thijsb
Can you provide some good reading material? I've been looking for some, but
except the elixir docs and phoenix website, at lot of resources that I have
found are outdated or poorly written.

~~~
phamilton
If you want to truly understand Elixir, go through the book/site Learn You
Erlang For Great Good. Understand it in Erlang, then apply it in Elixir. Once
you get a feel for how to translate idioms from one to another, everything
will be much easier, since you can turn to either community for information.
You'll find that an undocumented library follows one of a small handful of
designs and a quick peek into the source is all you really need.

Once you get the Erlang->Elixir relationship, I recommend Erlang in Anger.

------
FullyFunctional
I've known and loved Haskell for more than a decade so when I was "encouraged"
to learn Erlang it expected to hate it. I was thoroughly surprised to see how
nice it is. As for the syntax, I mostly find it great (but obviously
different).

Something I find worth emphasizing: There is exactly one integer type and
integers are unbounded. Very few languages gets this right and it's IMO one of
the worst mistakes in Haskell. This takes care of a whole slew of bugs and
security pitfalls.

I'm still an Erlang n00b, but the lack of a native string type seems a major
weakness -- strings are isomorphic to a list of small integers, worse than
even Haskell. Please give us something based on Ropes, like in Cedar
([http://onlinelibrary.wiley.com/doi/10.1002/spe.4380251203/ab...](http://onlinelibrary.wiley.com/doi/10.1002/spe.4380251203/abstract)).
EDIT: typo.

~~~
kyllo
_There is exactly one integer type and integers are unbounded_

Isn't that one of the reasons Erlang is slower than Haskell though? Arbitrary-
precision arithmetic is much slower than Int64 arithmetic.

~~~
FullyFunctional
Even though the integer type is unbounded, in practice the vast majority of
runtime values are small, thus we can implement them efficiently using tagged
pointers [small values are completely contained in the pointer]. LISP and
Smalltalk have been doing this since the 70'es. Sun SPARC even _had_ hardware
support for doing it with no (zero) overhead, see tagged instructions
([https://en.wikipedia.org/wiki/SPARC](https://en.wikipedia.org/wiki/SPARC)).
Even on x86, it's not _that_ bad; the overhead for the general case is two tag
extractions and three predicable (not-taken) branches (we must check for
overflow), about five additional instructions. Not zero, but the dynamic
frequency of these is much lower in a high-level language than in, say, C.

The performance differences between Erlang and Haskell (etc) are due to many
reasons, but primarily due to Erlang being a dynamic PL, with late binding and
dynamic typing. This makes efficient implementation hard (heroic efforts on
JavaScript not withstanding), but Erlang makes no excuses as its strengths
lies elsewhere. If you need fast compute you should do it in C and interface
it with Erlang (lots of ways to do that).

------
vezzy-fnord
I actually enjoy the language itself. Functional, but not tacit. The module
system provides good namespacing boundaries and package encapsulation. A data
type-driven programming style emphasizing pattern matching on primal terms
like tuples and lists. Good syntax for list comprehensions. On and on.

I would switch to Elixir, but the syntax is too weird.

~~~
lectrick
> but the syntax is too weird

Ah, I've finally found someone in the wild who thinks Erlang's syntax is less
weird than Elixir's! ;)

~~~
jwatte
Elixir fixed all the things that didn't matter, and made all the things that
matter harder and more expensive. Raw Erlang is better for anyone used to more
than three languages.

~~~
lectrick
As a guy who's been doing Ruby for 10 years, syntax matters very much to me.

> and made all the things that matter harder and more expensive

... Explain?

> Raw Erlang is better for anyone used to more than three languages.

While I can read and write "raw Erlang", I prefer Elixir, for whatever reason.
The macro facility alone is far more powerful than anything Erlang can
provide, I enjoy things like pipe |> which was taken from... crap, forgot
which language...
[http://danthorpe.me/posts/pipe.html](http://danthorpe.me/posts/pipe.html),
protocols are a useful addition, and strings are natively-supported UTF-8
binaries and not arrays (well, you have both actually, depending on whether
you single-quote or double-quote the string). And while both seem to be
roughly as terse, I just find Elixir to be far more readable and more-
organized-looking, compare Shannon entropy algorithms here for example
[http://rosettacode.org/wiki/Entropy#Elixir](http://rosettacode.org/wiki/Entropy#Elixir)

Anyway, a lot of it is opinion, but I think it's good from anyone's
perspective that Elixir is ultimately bringing more clever people onto the
BEAM VM.

~~~
cheepin
The pipe operator came from OCaml I believe and is also used in F#. Huge
convenience for functional langauges.

~~~
lectrick
aha! Yes, OCaml. And F#. Although I think, OCaml was first.

------
bsder
Choose Erlang when your single most important characteristic is _uptime_.

Erlang is excellent for problems where latency is an issue. It's really good
for problems where scaling is an issue.

But uptime is the big one. The whole immutable, recursive calls, and kill-and-
restart quickly is a very good architecture for when you need all those nines.

~~~
MichaelGG
Can you elaborate on kill and restart? I feel I must be missing something. How
is restarting processes different than wrapping workers in a try/catch, or
just restarting OS processes?

More interestingly, how does this help uptime? I've been in telephony for a
while. My software related downtime (vs human error breaking things) seem
either related to logic bugs (restarting won't help) or load (simply too
little hardware for a, say, 100x increase in traffic).

Maybe Erlang's selling points make more sense compared to C instead of a
managed language? For instance I often hear about the robustness of the Erlang
VM, yet JVM or CLR integrity has never been an issue for me.

~~~
bsder
The other comment here recommending that you research it yourself is spot on.

Nevertheless, I'll try.

In Erlang, almost everything is immutable. So, if you want to update state,
you build a new state, and then call yourself recursively with the new state.
Seems annoying, right?

 _Except_ , I can invert this where I keep the state the same but vary the
_code_. If I want to update my code, I can tell the old code to pack up it's
old state and call my new code recursively.

No downtime. At all.

Robustness: the Erlang VM keeps track of a cost for just about everything in
its preemptive scheduler. The scheduler is tuned for _latency_ rather than
throughput. So, when you get 100X increase in traffic, the scheduler continues
to make progress even if it's resource is getting overloaded. In addition GC
pauses are per scheduler/process rather than global. This is a function of the
fact that Erlang tends to serialize nearly everything so it doesn't have to
share.

As for kill/restart, these things tend to be an architectural idiom that is
shared by the standard library rather than an obscure technique that only a
handful of the programmers grasp. Kill/restart is expected to be _NORMAL_ in
Erlang and is thus fast with low overhead--try/catch tends to be abnormal and
restarting OS processes tends to be slow.

There are a lot of good things wrapped into Erlang. If you've just used
imperative C variant languages (C, Java, C#, Python, Ruby, etc.), I recommend
using it in a bit of anger. It can be frustrating until you get your head
wrapped around it, but I still retain the architectural elements when I write
certain tasks in other languages.

------
nextos
It's really really enlightening to see how you can build Erlang as a Prolog
DSL. Since Prolog is homoiconic, it's quite easy:

[http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AD...](http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AD9019868EB657DD1BCEB3900849D82?doi=10.1.1.34.3972&rep=rep1&type=pdf)

That's actually how Erlang was born, hence the apparently odd syntax.

------
MCRed
When you want to scale across multiple servers without much effort.

~~~
devbug
Multiple. Scaling to a multitude takes a lot of effort.

~~~
lectrick
Are there any tools to help with "multitude"-level scaling?

It's been my experience (across all langs) that every new order of magnitude
of scaling requires a new technology/technique/architecture...

~~~
devbug
Not to my knowledge, no.

Sorry.

~~~
lectrick
So folks like WhatsApp basically do homegrown solutions?

