Now in my estimation Functional Programming in Erlang should have benefitted any Elixir developer wishing to improve their handle on functional programming principles, in particular:

Effective use of pattern matching (i.e. not just here and there - but everywhere)

Effective use of body and tail recursion.

Effective use of higher order functions, especially foldl/foldr, map, filter and related

The Erlang shouldn’t be a hurdle to anyone using the basics of Elixir - it may not feel as “nice” to some but to me Erlang has a very practical, “get stuff done” feel about it.

However don’t be fooled by the “5 hours per week for 3 weeks”. Doing that, you might as well be flipping through a magazine for all the good it does. You have to be prepared to do the exercises and assignments to get the maximum benefit and that is going to take a significant amount of time and effort.

Now there were repeated complaints that the exercises were not based on “real world examples” - but the exercises were chosen to maximize the density of problem solving opportunities for application of pattern matching, recursion and higher order functions. “Real world examples” would likely make the course even longer without necessarily covering more ground.

Granted, while I didn’t find the subject matter of the various exercises all that engaging, the functional programming problem solving going into the final “rock, paper, scissors” strategies implementation exercise ultimately was quite engaging.

To close off here are some choice quotes from Erlang Master Class 1: Video 8 - Discussion:

FRANCESCO CESARINI: And the six months, it’s not a learning curve. It’s more of an unlearning curve. So unlearning the object-oriented way of doing things.

FRANCESCO CESARINI :

The first hurdle is pattern matching.

The second hurdle is understanding recursion and the whole concept of tail recursion versus non-tail recursion.

And the third kind of hurdle is thinking concurrently.

JOE ARMSTRONG: And both of you, what do you think the best way to learn Erlang is?SIMON THOMPSON: Practice. Practice. … You don’t learn to swim by reading a book about swimming. … things become easier the more you do them.

JOE ARMSTRONG: So once you’ve learnt Haskell, up to monads and things like that, it looks very much like Erlang. You just move the brackets around a bit. You take the brackets out, actually, and you move the commas, there’s less syntactic noise.

FRANCESCO CESARINI: I found Haskell and Erlang, at least when taught in university, is very complementary of each other as well. And my opinion is that any student taking a computer science degree should learn both.

FRANCESCO CESARINI: I mean, we use Erlang as the glue to handle the whole orchestration. And then we use Python, C, Julia. No not at all. It is actually language intended to act as a hub towards other languages. And Interfacer could be protocols. There could be a RESTful APIs or other programming languages. It’s ideal for that.

JOE ARMSTRONG: When I teach it, the students start asking where’s the debugger? And I say, well, there isn’t a debugger. Or there is a debugger, but no Erlang programmers use it. And they say, well, why’s that? And I say, well, because you don’t have variables that are changing under your feet that it’s difficult to reason about it. Once they’ve got a value, they’ve got the value forever, and they acquire it in one place, and therefore, you don’t need to track it.

FRANCESCO CESARINI: I would judge where not to use Erlang, I think two very distinct cases are, for example, number crunching, and your graphical interfaces, the libraries, are appalling.JOE ARMSTRONG: So if you had to choose one strong point for Erlang, what would you say was its unique strong point?FRANCESCO CESARINI: Massive concurrency. Orchestration. The fact that your systems behave in a predictable way under extreme heavy load, extreme heavy load under an extended period, or under extremely high peak load as well. You won’t get any degradation of throughput in your system.

JOE ARMSTRONG: So if you had to choose one strong point for Erlang, what would you say was its unique strong point?

FRANCESCO CESARINI: Massive concurrency. Orchestration. The fact that your systems behave in a predictable way under extreme heavy load, extreme heavy load under an extended period, or under extremely high peak load as well. You won’t get any degradation of throughput in your system.

The course is primarily about working with message-passing-based concurrency and for the most part was taught in terms of the raw concurrency primitives . But ultimately all this exposure at the lower level was designed to persuade the participants to actually (continue to) work with OTP instead.

The first course focused on “the functional Way” while this course focused on “the message-passing concurrent Way”. As with the first course the topics operated with a very compact core set of Erlang features that really should not present much difficultly to a practicing Elixir developer (as long as one is a bit open minded about it being different) - if one wishes to get a sense of “the Way”.
(I’m not expecting these courses to be remastered for Elixir - as it really isn’t necessary).

The first week revolved around sequential vs. concurrent code, introducing the spawn, ! (send), self and receive concurrency primitives and some of the operational details of a process’s mailbox. Shortly after that the frequency server was introduced as the basis for a peer-reviewed assignment - timeouts were to be added for the purpose of preventing receive deadlocks and purging stale messages.

The second week covered a selection of fault tolerance topics leading with the introduction of the “Let it fail” design philosophy which segued into a treatment of process links, exit signals, and exit trapping which was capped off by an exercise to add exit signal handling to the frequency server to certain effect. The week’s topics then continued with supervision which lead to the assignment of introducing a supervisor process to the frequency server. This was then followed by a number of exception handling topics. Possible scenarios leading to race conditions were alluded to and finally the topic of hot code reloading was introduced and demonstrated with an exercise.

The third week lead with some overview of scaling and distribution topics before getting to “separating the generic from the specific” as an introduction to OTP. After the frequency server as a gen_server exercise, miscellaneous Erlang features like macros, records, maps and binaries were given a quick introductory overview followed by an overview of some of the more commonly used tools in the Erlang ecosystem.

There are two courses offered by the University of Kent online. They are Functional Programming in Erlang and Concurrent Programming in Erlang. I am half way through Concurrent Programming in Erlang, which is supposed to be the 2nd course from what I gather. It is following along with the book, Designing for Scalability with Erlang/OTP. You can get a certification or take the course for free.

At this date the is no new date for Concurrent Programming in Erlang (it wouldn’t surprise me if they are holding that one back for autumn - especially if the proposed OTP Programming in Erlang is expected to be ready by then).

I took both of the courses (Functional and Concurrent) and can vouch for both of them. After you take the first course you will have a good grasp on Erlang, it’s a really simple language overall.

The second course does a good job of teaching you the concurrency model. Most of the course is teaching you just the concurrency primitives (send, receive, spawn, links, monitors, trapping exits, etc). You work your way up implementing your own supervisors and genservers using just the primitives, and then finally you are introduced to the OTP versions. You get a good understanding of how genservers and supervisors work and what they’re doing for you behind the scenes. You also get introduced to a lot of little race-condition gotchas and how to work around them.

I think starting from the bottom and working your way up is a good method of learning about the concurrency model. If you come from some ‘normal’ imperative language and are introduced first to the genserver api it probably looks a little odd. You have these functions that are returning specific tuples, call vs cast vs info, this magic State variable you pass around. It can seem really arbitrary without knowing about the standard process Loop pattern and how basic messaging conventions work under the hood.

The same can be said about supervisors. If you’re introduced to supervisors first they seem a little bit magical. Knowing that they are themselves just regular processes that have links to their children puts them in perspective a bit.