

Erlang OTP Tutorial For Beginners - signa11
http://blog.bot.co.za/en/article/349/an-erlang-otp-tutorial-for-beginners

======
ericmoritz
"OTP in Action" is an excellent book for learning OTP.

The following reading will take you a long way with Erlang:

Learn you some Erlang <http://learnyousomeerlang.com/>

OTP In Action [http://www.amazon.com/Erlang-OTP-Action-Martin-
Logan/dp/1933...](http://www.amazon.com/Erlang-OTP-Action-Martin-
Logan/dp/1933988789)

On Erlang, State and Crashes [http://jlouisramblings.blogspot.com/2010/11/on-
erlang-state-...](http://jlouisramblings.blogspot.com/2010/11/on-erlang-state-
and-crashes.html)

"Making reliable distributed systems in the presence of software errors"
<http://www.erlang.org/download/armstrong_thesis_2003.pdf>

The last two links are "Erlang propaganda" describing the hows and whys of
Erlang.

~~~
anactofgod
And, for those desiring augmentation/enhancement of their own self-directed
text-based learning of OTP and Erlang, two of the "Erlang and OTP in Action"
authors, Martin Logan and Eric Merrit, with Jordan Wilberding and Ram C Singh
(full disclosure: that's me), teach ErlangCamp, an intensive two-day course in
building large-scale Erlang applications using OTP.

The class is suitable for those with some experience with programming, though
Erlang expertise is not required. It is based on the book, but structured
differently. The class starts with the teaching of the essential aspects of
Erlang required for one to become functional with OTP, then moves quickly into
an introduction of OTP. The remainder of the class is spent building on these
foundational Erlang and OTP concepts.

Two ErlangCamps are in the planning for this year. One will likely be in the
Europe (date/location TBD), and the other in the US, targeting "Music City",
Nashville, TN, in October. If interested, monitor the ErlangCamp website
(<http://www.erlangcamp.com>), which will be updated with details, as we lock
them down.

------
oinksoft
Those interested in this topic may find [http://learnyousomeerlang.com/what-
is-otp#the-common-process...](http://learnyousomeerlang.com/what-is-otp#the-
common-process-abstracted) of interest. It has similar aims but doesn't take
detours for rebar, emacs and such (things you don't _need_ for Erlang/OTP).

------
MichaelGG
I never understood why you have to take Erlang-the-language to get the
distributed systems platform. It seems like the whole node
management/serialization/"process" management and whatnot could apply to other
languages and runtimes.

That way you could get Erlang's distributed platform, which is highly lauded,
but mix it with a faster or more preferable language.

~~~
rdtsc
> I never understood why you have to take Erlang-the-language to get the
> distributed systems platform.

That is a very good observation. And I used to have the exact same question.
It took a while to realize why Erlang is they way it is, and it makes sense to
me now. I don't mean the parsed syntax, see Reia and Elixir, but its main
features.

You have to go back to the roots and see why was Erlang created. Its primary
focus was fault tolerance and secondary was concurrency. Everything else fell
out of those.

For example:

* Actor model : it provides isolation in a large system so only a single actor process crashes on failure and it can be restarted. This means no large pool of pointers, shared data, etc. It means message passing. There is an anecdote that some systems written in Erlang are sold with contract that stipulate that any downtime longer than 4 minutes / year will be billed at $10K/minute. With these kind of goal everything has to change. Segfaults are not something that can crash the system. Too expensive. Stopping the system to upgrade and get a bugfix in -- no can do, too expensive. Also concurrency fits in here. Actors work concurrently and are responsive, their are designed to have responsiveness (low latency) over raw throughput.

* Hot Code Reloading : falls out of needing to have high uptime and fault tolerance. This means system gets updated while it runs.

* Functional Syntax : functional syntax encourages creation of referentially transparent pieces of code. This helps with hot code reloading as there is less state modified in place, rather it is passed throw the function calls.

* Single Assignment : pure torture for those coming from imperative programming. But necessary if values are to be passed between processes or if the code is upgraded on the fly. You gain a large amount of safety know that the variable X you just instantiated won't change behind your back.

* Multi-node (multi process and multi machines) distribution: for real world reliability you can't just rely on one machine, you need to have hot spares for fail-over. What takes complicated messaging and sync protocols, haproxy, message queues, zookeepers and other tools comes bundled in Erlang's standard library.

[http://learnyousomeerlang.com/distributed-otp-
applications#a...](http://learnyousomeerlang.com/distributed-otp-
applications#adding-more-to-otp)

As a bonus, it has one of the best pattern matching syntax I have seen. Once
you start using it and get the hang of it you'll miss Erlang's pattern
matching in every other language you use.

There are downsides to Erlang in terms of pure numerical performance. This is
the other coin of fault tolerance and latency reduction. You can't have both
there are some trade-offs involved.

~~~
MichaelGG
Thanks for the response. It seems that if you go for full message passing and
enforce immutability, then you're already a good way on the path to being able
to do hot reloading (just load the new code, and point messages at the new
address) and so on. Erlang doesn't _magically_ make this stuff go away, you
still have to be aware that you're sending messages cross-machine.

I've spent a couple of days playing with Prolog, so if Erlang has matching
similar to Prolog it'd be a step up from ML-style. Although I'm not really
sold on not being able to _rebind_ a variable name (not mutate the value). I
can't see any reason for restricting that.

------
plainOldText
I'm very happy to see more OTP tutorials as of lately. I believe OTP can be
one of the most powerful tools in an Erlanger's arsenal.

~~~
jerf
Stronger: If you are using Erlang for anything real and you aren't using OTP
you are almost certainly doing it wrong.

~~~
spfoos
Good point. About the only thing I've found is the lack of pooling
gen_server's built-in and limitations of using atoms for process registration
as things I have design a solution for in OTP. Otherwise, architecturally, I'm
amazed at how much ground is already designed in OTP.

~~~
omarkj_
From R15B01 you can actually use "plugins" for process registering using the
{via, Mod, Key} syntax.

Gproc supports this and using it you can do stuff like:

    
    
      gen_server:start_link({via, gproc, {Your, "very", <<"complex">>, key}, [...])
    

you can also roll your own.

Docs: <http://www.erlang.org/doc/man/gen_server.html#start_link-3>

