And we’re following up with a MOOC on concurrent programming in Erlang, too.

If I understand correctly the content of Functional Programming in Erlang is accessible for another two weeks, after that it is only available for those who have paid for an upgrade.

The three weeks of Concurrent Programming in Erlang will cover:

1. Processes in Erlang
2. Fault Tolerance in Erlang
3. A “little bit” of OTP

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.

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.

Concurrency means the possibility of running independently perhaps at the same time.

The Concurrent Programming in Erlang course will remain open for free until 2017-May-08.

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 Frequency Server from Erlang Programming serves as the teaching vehicle for most of the course. (The Frequency Server also makes an appearance in Designing for Scalability with Erlang/OTP). The final exercise is to convert it to a version that is based on OTP’s gen_server.

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.

The weekly feedback videos are available on YouTube:
Concurrent Programming in Erlang: week 1 feedback
Concurrent programming in Erlang: week 2 feedback
Concurrent programming in Erlang: week 3 feedback

There are plans to potentially add a third course focusing on OTP by the end of the year; presumably about design strategies and real product “war stories”.

I have signed up the course. I’m new to both Erlang and Elixir, so I hope to learn some foundation of functional programming and help me get started in Elixir