In Erlang you world revolves around processes. Not to be confused with OS processes. Here we are talking about highly light weight threads that can quickly be started and shut down. These are a lot faster and lighter that threads you may be used to from Ruby and you will use them quite a lot more than usually happens in Ruby. The best part is that this great power of Erlang is one of the simplest things to do. You just simply use the spawn(module, function, [parameters]) command to start a function and it starts it as a process. Really thats it. Lets see an example of this by starting the recurse command from part 2: P1 = spawn(demo,recurse,[[1,2,3]]).. Now this process started and ended within a second but imagine if this would have been some call to some webserver taking up to a few seconds. There the process would have done it's thing and the creating function continues doing it's thing without having to hang around for results.

This is how you should do your Erlang programs. You should avoid as much as you can having your program waiting for some action to complete. Instead you should have a bunch of processes communicating with each other.

Sending and Receiving Messages

Now. It's not enough in most cases to just spawn the process and let it run until it finishes. Often you must talk to that process and as they do not share memory with each other they need to talk to each other by passing messages. Luckily this also is as simple as it gets.

The return value of a spawn function is the Pid of the Process. In the example before we bound the Pid to variable P1. We then could just send a message to it simply by saying P1 ! [1,2,3,4].. If we expect a response back we often send our own Pid within the message and we can get the Pid of current process with the command self(). In that case the message might look like P1 ! {helloworld, self()}..

It's no use sending a message if the receiving process is not listening. Enter the receive consturct. The receiver waits for a message and when it receives that message it tries matching it to a pattern and runs the corresponding actions. Lets look at a receive block.

receive
  [Head|TheRest] ->
    io:format("Got a list with the head: ~p ~n",[Head]);
  {helloworld, CallingPid} ->
    io:format("Got a hello world. Saying hello back. ~p ~n"),
    CallingPid ! {response, "Hi Back"};
  MatchAll ->
    io:format("Error: Dont know what do do with ~p ~n",[MatchAll])
end.

Here we have 3 possible messages to receive. This works in general much like when we define multiple versions of the same function.

Registering

One thing that I will mention before giving an example of using processes is the concept of registering process under a name. Often it's not convienient to store a Pid in a variable since variables only exist within a function. There we register the Pid under a name with the command register(Name, Pid). For example we could call register(servername, P1). and from now on we can always make the call servername ! {helloworld, self()}. from anywhere inside that node.

A Simple Example of Processes

Lets take a look at an example code. Lets open our demo.erl from Part 2 and add start_server/0, start_server/0, remote_convert/1, server_loop/0 to the exports. Go to the end of the file and enter the following code:

start_server() ->
  Pid = spawn(demo, server_loop, []),
  register(converter, Pid).

stop_server() ->
  converter ! shutdown
  unregister(converter).

server_loop() ->
  receive
    {convert, cm, Value, CallingPid} ->
      CallingPid ! {inch, Value / 2.54},
      server_loop();
    {convert, inch, Value, CallingPid} ->
      CallingPid ! {cm, Value * 2.54},
      server_loop();
    shutdown ->
      true;
    MatchAll ->
      io:format("Got a message I don't understand. ~n"),
      server_loop()
  end.

remote_convert({Unit, Value}) ->
  converter ! {convert, Unit, Value, self()},
  receive
    {NewUnit, NewValue} ->
      io:format("Result: ~p ~p~n", [NewUnit,NewValue]);
    error ->
      ok
  end.

Lets take a look what happens here. We start by compiling and running demo:start_server(). that spawns server_loop/0 as a process and registers the Pid as converter. Next up is stop_server/0 that sends a message to the server asking it to shutdown. Third is server_loop/0 has a receive block that waits for 4 matching messages. First 2 are tuples requesting a unit conversion. It converts and sends a message back and then calls itself so it can wait for the next message. The shutdown message really does nothing except not calling for the loop to repeat. MatchAll will handle all other messages and write out an error.

remote_convert/1 then manages calling the server and then waits for a message back. Lets try it out by running demo:remote_convert({inch,1}). and you should get a message back.

Funs

Funs are basically blocks. And much like you do in Ruby you will use funs a lot. A simple example of a fun would be:

Double = fun(X) -> X*2 end.

Then you could make the call Double(10). and the result would be 20. Much like you do in Ruby you will often use Funs as parameters to functions. An example of a function that takes a fun is lists:map. This is a non object oriented version of Ruby's Array.map. It's first parameter is the fun to be run on each element and the next element is the list itself. Here we would make the call:

lists:map(fun(X) -> X*2 end, [1,2,3]).

To create a new list with each element multiplied by 2. Another way to get the same result are by using list comprehensions.

List Comprehension

List Comprehensions are a great feature to create lists or manipulate lists. Lets start with the simple expression

[X*2 || X <- [1,2,3]].

This would create a new list with each element doubled. In english this would read "double each X where X is [1,2,3]". What is before || is called the expression and what comes after is referred to as the qualifiers. There can be multiple qualifiers like the example

[X || X <- [1,2,3,4], X > 2].

This would give out the result [3,4]. Here we the english term would be "display X where X is [1,2,3,4] and X is greater than 2".

A great example of how to use this can be read at WikiBooks. Here they give an example of using list comprehensions to solve an equation. The output of:

[ {X,Y} || X <- [1,2,3,4], Y <- [1,2,3,4], X*X == Y].

Would be [{1,1},{2,4}] and should be read "A tuple with the values X and Y where X is [1,2,3,4] and Y is [1,2,3,4] and where X time X equals Y". And how cool is that.

A type of list comprehension is also used in the powerful mnesia database system to query results instead of SQL. I highly recommend that you get to know it well.

Modules and Functions

The modules are really a collection of functions if you simplify things. There are differences of course since it's not objects you are working with. Lets just start with a simple module from the Erlang website. You can put this in a file called demo.erl and run the command erl in the same directory. You then compile the file typing c(demo). in the Eshell and run it by entering demo:double(2). to get the result 4.

-module(demo).
-export([double/1]).

double(X) ->
  times(X, 2).

times(X, N) ->
  X * N.

The first line is the name of the module. This must match the filename with the .erl extension excluded.

The second line is a list of what functions are exported. Only exported functions can be called from other modules. The list includes the function name and its arity. The arity states the number of parameters the function calls. If you want to export both functions the line would read -export([double/1,times/2]).. Note that you can have 2 functions with the same name but different arity and you would then have to export both versions.

Next up are the functions. This is pretty self explanatory. First up is the functions double that take one parameter and calls the second function times. Times takes 2 parameters and multiplies together.

One thing to notice is the dot (.) at the end. The dot says that this function is done. If this was a multi line function each line would end with a comma (,) except the last line that would end on either a dot or a semicolon (;) if the same function with the same arity is defined. Now this may sound a but confusing but lets look at how it works. The boss has asked me to change the double function that the whole company stands or falls with so that it would give me an error message if I decide to be a fool and double the number 0. If I were in ruby I might just add an if statement inside the function but this is erlang and things are done differently. Lets delete the whole double function and replace it with the following and recompile:

double(0) ->
  io:format("Only a fool would double a zero ~n"),
  0;
double(X) ->
  times(X, 2).

Here we see basically the same function twice. What happens here is really the same as the pattern matching in part 1. if we make he call demo:double(2). the erlang system first tries to match with double(0). Since 0 == 2 can not match it goes down do double(N). There it sees that it it can make true the statement X == 2 if X holds the value 2 and runs that function. Here we also see the the uses of commas and semicolons. First line in double(0) prints out a message to STDOUT and then the comma says that another statement is to follow. Then put out a single 0 because like in ruby the last statement is the return value of the function. This is followed by a semicolon to say that the function is over but that the same function will return but for a different value (It's actually not that simple but it's the simplest way to explain the behavior). Then at the end we have a period to say that all version of the function is over.

Another common way of usage is using tuples. Lets add convert/1 to our exports at the start of the file, add the following to the end of the file and recompile.

convert({cm, Value}) ->
  {inch, Value / 2.54};
convert({inch, Value}) ->
  {cm, Value * 2.54}.

Here we call convert/1 with a tuple. The first element in the tuple is the current unit of length and the second element is the value in that unit. It then returns a tuple with the new unit and the converted value. So the call demo:convert({inch, 1}). would give the result {cm, 2.54000}. Here we see in a great manner why we often have the first element in the tuple define what the whole tuple is like I mentioned in part 1.

Recursing Functions

One thing that, if you would do in ruby, would call for a lynching mob after you are recursive functions. In Erlang it's standard practice. Functions quite frequently call themselves. Lets look at an example of recursion by adding this to our demo.erl. Don't forget to export recurse/1.

recurse([]) ->
    io:format("All done.~n");
recurse([First|TheRest]) ->
    io:format("Value: ~p ~n", [First]),
    recurse(TheRest).

When we call this with an list like so: demo:recurse([1,2,3]).. it will first try to match with recurse([]) and be unable to do so since it's not an empty list. It will however match with the second function and create 2 variables. The variable First will hold the first value in the list and will be printed out but TheRest will hold the rest of the list. Then it calls itself again with the shortened TheRest list. In the end the list will be empty and match the first definition of recurse/1.

Conclusion

This should be good for now. Next article will go into processes mainly and give a little overview over the OTP principles.

Erlang is a wonderful tool to learn and gives you the same enjoyable programming experience as most have with Ruby. And it's a great match to use them together in a product. Ruby for the front end to ease making a good user experience with trusty old Erlang in the background making sure everything is rock stable.

The power of Erlang lies in it's ability to be scalable and stable. To put it bluntly. If your Erlang application is unstable and does not scale well then you have done something wrong.

The Shell

We start off on a familiar ground. The main Erlang executable is the command erl. This should instantly feel as home to Rubyist and remind of trusty old irb. What it can not do however is create the modules and functions. It can only call them. However it's powerful and you should expect to spend a lot of your time inside there. Remember to end your statements with a period to execute them.

Variables

Variable start with a capital letter. The first thing that shocks people is the fact that you can only set a variables once. Thus typing Var1 = 1 and then immediately Var1 = 2. would give you an error. Think of it as a strength though rather than a problem. The simple, money back, guarantee is that this will never be a problem for you and you won't need to think about this since functions are short and variables only exist inside the function. What usually happens is that people start actually liking having the variables single-assigned since it tends to simplify things and reduce errors.

Atoms are Symbols

Atoms start with a downcase letter or are enclosed in single quotes. They can not hold any value and represent only themselves. They are basically the same as symbols in Ruby. One thing to remember is that atoms do not disappear from memory after being created so if you in some way create them dynamically you may fill up your memory after a while. This may not sound like a problem at first but remember that your goal is probably to create an application that will run for months or even years without being restarted.

Lists and Tuples

Lists and Tuples are similar in many ways. Both represent a collection of elements. The difference is that lists have variable number of elements while tuples have fixed number of elements. Lists are defined between [...] while tuples are between {...} I read somewhere that lists are like arrays while tuples are like hashes. That is 100% totally incorrect. Tuples are nothing like hashes. The most common use of tuples you will see is that the first element is a atom that explains the rest of the tuple. For example the tuple {error, 404, "File Not Found"}. Often you will also use a list of tuples. For example [{person,"Steve"},{person,"Joe"}]. How this all matters is best explained in the next section.

Matching (or how = is not =)

The equal sign behaves quite a bit different from what you are probably used to. It's behavior is called Pattern Matching. What it does is to try to make the statement true and the simplest example is X = 1. Here erlang finds that the only way to make the statement true is if the variable X stores the value 1. Here we also see the difference in using tuples and lists. If we make the statement {error, ErrorCode, ErrorMessage} = {error, 404, "File Not Found"} it will find that to make this statement true it has to assign the variable ErrorCode to "404" and ErrorMessage to "File Not Found". Pretty nifty eh? With lists you can do things like [FirstElement|TheRest] = [1,2,3,4]. Here the variable FirstElement will become 1 and TheRest will become [2,3,4].

Conclusion

This is it for now. In the next article I will explain amongst other things modules and functions along with the real power of Erlang that lies in processes.

Or if you want to dive into actually learning Erlang I would recommend Kevin Smith's excellent screencast Erlang in Practice.