techblog 

Well, I had hoped that my first foray into Erlang might have got further - instead, I fell for the first trick in the book…

I wanted to write a little udp server which I could grow into something more interesting. The server side seemed to work just fine, but for some reason I simply couldn’t get the server response to reach the client. The client had code of the form :

  query(Msg) ->
    {ok, Socket} = gen_udp:open(0, [binary]),
    ok = gen_udp:send(Socket, “localhost”, 4545, term_to_binary(Msg)),
    Value = receive
                {udp, Socket, _, _, Bin} = Msg ->
                         % deal with the response message
   . . . .

Of course, the Msg variable is already defined by the time the response returns, so the first pattern in receive will never match (presuming that the response is different to the query).

I really shouldn’t be copy-pasting code (which is how Msg ended up in two places in the same function. However, I’m obviously going to have to get my eye in for this sort of thing if I’m going to be doing much with Erlang. It took me far too long to find this obvious bug!

I’ve been spending some time learning Erlang recently. It’s a language which has interested me for some time now, so I’m happy to be getting the chance to evaluate it for a new project. I like the fact that it’s been designed for concurrent distributed systems, and shares a common ancestor with occam (a language I enjoyed coding in the past). These languages eliminate many of the problems of concurrent programs by having no shared state (although Erlang comes with mnesia, a distributed database). Instead, many otherwise completely independent processes communicate entirely by sending messages to each other (which accumulate in a process ‘inbox’). These processes may then be supervised by other processes on other machines, resulting in a highly concurrent fault-tolerant system. Sounds great!

On the down side, first forays into Erlang do reveal its long history. The origin in the 1980s is obvious, and the poor and sparse documentation and support is probably the result of a proprietary commercial system going open source. Symbian OS also suffered from poor documentation when it was first opened up to a wider community - this got much better with time, so hopefully Erlang will be easier to get to grips with in the future.

The debugging could certainly be easier - maybe I’ll work out the meaning of the arcane error reports one day…