This *is not* it:
I propose that the purpose of a "Hello, World!" program is to communicate something essential about the programming language in a small space. The program above does not achieve this - relative to implementations in other languages - predominantly because it omits anything to do with the Actor model, which is a core part of what makes Erlang interesting.
I propose that the following should be considered The Real Erlang "Hello, World!":
spawn(fun() -> loop() end).
Let's dissect this example to see why. To run this program, install Erlang, fire up the Erlang REPL
erl.exe and follow along.
First we compile and load the program with the command
c(). Note that we omit the ".erl" file extension when referring to the module. Also note that I started
erl.exe in the directory containing
hello.erl such that I was not required to type in the full path.
Erl responds with
ok and the name of the compiled module.
start() function is the only function we can invoke in the
hello module, because it's the only one that is exported, as per the module's export statement. This is how Erlang implements encapsulation, in that the exported functions form the public interface of the module. The list of exported functions are of the form
name/arity, where name is the name of the function and arity is a formal way of saying "the number of arguments it takes".
start() function within the
hello module, assigning the return value to a variable called
2> Pid = hello:start().
spawn function returns a Pid - a Process Identifier - which is a first-class Erlang data type. We assign this return value to a variable of the same name. (We could just as easily have assigned it to a variable named
Foo, but using
Pid is fairly common). Note that variables in Erlang need to start with an uppercase letter.
Erl responds by pretty printing the process identifier
<0.36.0>; all valid expressions in Erlang have a return value.
At this juncture, if you try to assign any other value to Pid, you will get a
badmatch exception. Once a value has been bound to an identifier, it cannot change: Erlang is a single-assignment language. The benefits of this paradigm include the ability for the compiler and runtime to make fancy optimizations, and it also greatly eases debugging because variables are immutable.
The Sharp End
spawn invocation starts an Erlang process which wraps the
loop() function just below it. (Note that Erlang doesn't impose any order of definition on functions). Erlang processes are the essence of programming in Erlang, and the essential missing element in simpler "Hello, World!" examples. Processes are the Erlang implementation of the Actor model: extremely lightweight concurrency primitives that communicate purely by message-passing. They have nothing whatsoever to do with operating system processes, threads or similar, and are managed entirely by the Erlang runtime.
The process waits (semantically at the
receive statement) for a message which matches one of its receive clauses.
We can send a message to the process using an exclamation mark (the message-send operator) followed by the message. We can see that the receive block has two clauses which match both
We invoke the code within the 'hello' clause by sending the corresponding message to our cached Pid:
3> Pid ! hello.
As we expect, our process responds with, "Hello, World!". And as noted before, Erlang returns a value for all valid statements, this is why we see
hello printed out immediately following the output of
The following line does a tail-recursive call back to
loop(). In case you didn't follow the link and aren't completely familiar with tail recursion, you should know that tail-recursion is the bombay duck of computer science: there is no recursion going on, at least in the sense that anything is left on the stack. Tail recursion is a means of efficiently calling the current function, and is more akin to a goto or a jump instruction than the terminology would have you believe.
So, given the tail-recursive call back to
loop(), the process is once again put back into the wait state. We could send the hello message to Pid ad nauseum and the process would simply repeat.
Now we send the
4> Pid ! goodbye.
The crucial difference between this clause and the clause that matches the
hello message is that this clause does not include a tail-recursive call back to
loop(). As a result, the process effectively dies. We can confirm this by attempting to invoke the code in the
hello clause once again:
5> Pid ! hello.
And we see that no output is generated.
The last important detail that I have omitted is the type of
goodbye. These are erlang atoms, an extremely simple data type whose value is itself. Atoms are used heavily in message-passing (and other pattern-matching contexts) and are very easy to work with: you simply declare and go!
Although the explanation has been verbose, I hope you agree that this Erlang "Hello, World!" communicates some interesting essentials of the Erlang programming language. These essentials concern in particular how Erlang implements the Actor Model, which is the kernel of its message-passing semantics and a key enabler for Erlang's capability for massively concurrent processing.