Erlang from the perspective of a dev used to OOP – Part 1

So as many people out there I’ve also heard that Erlang was awesome, that all distributed computing problems were solved first by Erlang 30 years ago and so on. Decided to learn it. Surprisingly it’s not hard, and there’s an obvious reason for that.

Splitting hairs

First things first, Erlang as a name is ambiguous. It may refer to two things: the language or the runtime/VM (also known as BEAM). As in .net and java, there are  many languages targeting the Erlang VM, the most popular these days being elixir which combines Ruby syntax with some interesting meta programming capabilities.

That said, before jumping into elixir or something else, you should take some time to get acquainted with Erlang – the language. That’s what I did.

Concept count

To make this venture easier get used to this: you won’t find generics. Actually, let’s go further: no types. Well, no types that you can create, derive, subclass. And no objects, or to be more precise, no instances. Yeah, a functional language without OOP compromises. You still reading this?

Yeah, I know it sounds limiting but sometimes constraints are liberating.

The concept count of Erlang is minimal, which makes it extremely easy to learn it. In sum:

  • Atoms: you know, symbols that can be compared, are always “the same”. In Erlang (language) these are always expressed in lower case like true or false or exchange.
  • Numbers: you know them
  • Variables: which should start with Upper case like MyList. Oh, variables is a bad name since you can’t really change them.
  • Tuples: an aggregation of values like { one, 2, Three }
  • Lists: expressed as [ 1, 2, 3 ]
  • Records: which are more a language trick to make some things easier. In reality they are just tuples of name(atom) and a value.
  • Strings (or binary lists). Awkward, but I’ll get to them later

Unless I forgot something, those are the “things” you have to deal regularly when writing Erlang code.

Now IMHO the language syntax isn’t the most beautiful, terse, poetic you may find. But it’s practical and you get used to easily.

On future posts I intend to cover the following topics:

  • Modules and writing your first code
  • The shell + observer + debugger
  • Processes (the closest thing you get to an “instance” of something)
  • Pattern matching
  • Some OTP

YMMV and I’m not an Erlang expert. But after writing a fake security exchange that we use it here to run our integration tests and perf tests, I’m comfortable enough writing about it.

Your thoughts?