This *is not* it:
-mod(hello).
-export([start/0]).
start() ->
io:format("Hello, World!").
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!":
-module(hello).
-export([start/0]).
start() ->
spawn(fun() -> loop() end).
loop() ->
receive
hello ->
io:format("Hello, World!~n"),
loop();
goodbye ->
ok
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 commandc()
. Note that we omit the ".erl" file extension when referring to the module. Also note that I startederl.exe
in the directory containinghello.erl
such that I was not required to type in the full path.
1> c(hello).
{ok,hello}
Erl responds with ok
and the name of the compiled module.
The 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'sexport 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 formname/arity
, where name is the name of the function andarity is a formal way of saying "the number of arguments it takes".
Invoke the start()
function within the hello
module, assigning the return value to a variable calledPid
:
2> Pid = hello:start().
<0.36.0>
The 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 namedFoo
, 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 asingle-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
The spawn
invocation starts an Erlang process which wraps theloop()
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 theActor 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 itsreceive 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 bothhello
andgoodbye
.
We invoke the code within the 'hello' clause by sending the corresponding message to our cached Pid:
3> Pid ! hello.
Hello, world!
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 seehello
printed out immediately following the output ofio:format
.
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 thattail-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 goodbye
message:
4> Pid ! goodbye.
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 toloop()
. As a result, the process effectively dies. We can confirm this by attempting to invoke the code in thehello
clause once again:
5> Pid ! hello.
hello
And we see that no output is generated.
The last important detail that I have omitted is the type of hello
andgoodbye
. These are erlangatoms, 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!
Re-Entry Checklist
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 concernin particular how Erlang implements theActor Model, which is the kernel of its message-passing semantics and a key enabler for Erlang's capability for massively concurrent processing.
http://egarson.blogspot.com/2008/03/real-erlang-hello-world.html