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.
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.
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.
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 :)
> 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.
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.
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.
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.
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.
> I'm amazed at how much ground is already designed in OTP.
It is really like finding hidden treasure. And it used to actually be pretty hidden. There was no official book out there. Just had to dig through docs. There is OTP in Action now and I am glad to see others.
For example I had know idea about the existence of the distributed application controller, found out about it from a Learn You Some Erlang book.
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.
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...
On Erlang, State and Crashes http://jlouisramblings.blogspot.com/2010/11/on-erlang-state-...
"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.