Erlang OTP Tutorial For Beginners

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.

You don't, there's also elixir - http://elixir-lang.org. Elixir runs on the erlang VM but has a "nicer" syntax. (Nicer for some people, I don't mind it, but I don't think the syntax of erlang is a problem.)

Elixir is working its way to being a full erlang replacement, and apparently isn't yet one, but it replaces everything I need. It also has some really nice (And critical for my project) features that erlang doesn't have, due to the way its implemented. Namely, convenient code swapping in a way that would be hard for me to do in erlang.

The language is evolving pretty rapidly and has great guys behind it (Yurii Rashkovskii and José Valim)

You could build a platform that is concurrent the way erlang is... but the reason people use erlang is that nobody else really has.

There's a lot of stuff out there that's sorta pretending to solve these problems, but none that I've heard of have actually done the hard work.

It's not impossible, it just takes more commitment than most people are willing to invest.

Quite a few of us are very happy with the Erlang language itself. Many consider your idea something of a pipe dream because the Erlang VM and its process model relies on referential integrity, something you cannot exactly bolt onto a langauge. What you're going to end up with is a language that is semantically identical to Erlang with small visual differences. That's quite a bit of work for little gain, and you will lose ETS, Mnesia, and the other valuable Erlang APIs.

Another commenter mentions Elixir. I don't see how `def NAME do BODY end` is any better than `NAME() -> BODY.`

In the end I think that it's better to just learn Erlang.

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

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.

You don't. There are something to be said about the Erlang semantics though:

It is functional, which removes a lot of mistakes. Unlike other languages, there is fewer ways to "cheat" and use imperative features. It is a simple, yet powerful language. It got most of the semantics right. And it supports fault tolerance.

Fault tolerance means automatic handling of unforseen errors. This is not the same as an exception, mind you. Because you saw that possibility of an error coming from a long distance when you catch an exception. Error handling in Erlang lets you do far more than that.

As to getting a faster language, it depends. Erlang is built for low latency over throughput. So it depends on what you value. Do you want better interactivity and low latency, or do you want more throughput in your computation. Do note that most computationally intensive Erlang applications often contains portions of themselves written in other languages, typically C. Or portions implemented in hardware because C is too slow, but I digress :)

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

OTP isn't just powerful, it's essential. You need to think in terms of what OTP provides you to program in Erlang effectively.

OTP is more than just a framework it is really an important part of the language itself. Parts of OTP like proc_lib are built right into the VM among other close ties. This is why we focus our ErlangCamps 70% on OTP constructs and we wrote the book "Erlang and OTP in Action" and not just an Erlang book. We believe that an Erlang book would really only be describing half the language. When I say Erlang what I really mean is Erlang/OTP.