I just recently came upon a page devoted to introducing functional languages. Functional languages is an interesting concept since it approaches software development from a radically different angle. It focuses heavily on functions and immutability (in everything!). In some aspects it really shines when you understand it.
Erlang is a functional language developed by Swedish telecommunications giant Ericsson. It has a few nifty features and is reportedly used in some large-scale operations in live systems. It’s primitives and functional style makes it a breeze to unit test and debug. “While Java is scalable and stable, Erlang is rock-solid.”
One thing really stood out. It’s super-easy to create processes in Erlang, and it’s super-easy to communicate between processes. Using a simple spawn() statement on a function name, you just created a new process: (forgive me any syntax errors, I just started learning it)
% this is the 'doSomething' function
doSomething() ->
io:print("I'm doing something now.\\n").
% now call the function
doSomething(),
% now call the function asynchronously
spawn(module, doSomething, []).
Now, this asynchronous call – is it a new thread, or a new process? What’s the difference? Well, threads tend to share data within a process, while processes don’t share data. In Erlang, no data is sharable. So it makes no difference.
And if we, perchance, wanted to send a message to a different process? That’s easy:
% this is the server process
server() ->
receive
finish ->
io:print("I'm finished!\\n").
message ->
io:print("I got a message!\\n"),
server()
end.
% this is our client process
client() ->
Server = spawn(module, server, []),
Server ! message,
Server ! finished.
What happen? Someone set us up the server! Well, actually, client() set us up the server. What happens is that the client() call first invokes spawn() on the server function. server() happily goes into play, waiting for a message. The client then sends two messages to the server process, one “message” message and one “finished” message. The server call traps the first one, printing out “I got a message”, and then restarts the server process. Then the “finished” message is trapped, the server prints “I’m finished”, and with nothing more to do, it exits.
How is that for super-easy?
I’m thinking of the Nav service (“Hub service”, technically) that we used for intra-process communication at my last job. Communication between processes worked rather efficiently, but with certain amount of hassle. Each process logged in, registered itself, waited for and sent messages. With Erlang, that whole part could have been rationalized down to a few lines of code.
Now I’ll just see if I can build a process-and-messaging API that is somewhat as efficient as this in Delphi … before my benevolent Java friends alert me to the fact that this already exists in Java. Most likely.