A Pythonista's Impressions of Erlang
I am planning to write a poker server in
. Why? A couple of reasons.
First off, I have heard that the concurrency support in it is excellent.
Secondly, A quick glance gave me the impression that it was, at least, not
brain-dead. Third, it's been a long time since I learned a new language, so I'm
planning to do it for kicks.
As such, for the last few days, I've been playing around with the language, and
I have begun to form my opinions on it. Since I've been pretty busy, I haven't
had too much time to play with it, and as such my opinions are half-baked.
Since that never stopped me from writing before, here they are.
If I'm wrong somewhere (and I'm sure I am) drop me a comment, and I'll fix it.
- Interpreter: Erlang has a shell that is very similar to Python's. I
am totally addicted to the Python shell, so this makes experimentation quite a
bit easier. It features some comforting functions: m(module_name). lists the
functions exported by module_name, and length([1,2,3]). returns 3.
- Pattern Matching: I *love* this feature. If I were to make a serious
switch to Erlang, pattern matching would be a large reason. I'm not sure how
well it works in large applications yet, but it certainly feels elegant to
With pattern matching, you can define one function multiple times, and Erlang
will pick the appropriate function based on its signature. Perhaps an example
will help; you can define your basic factorial function like so:
Erlang will automatically call the first function when the argument is zero,
and the second one otherwise.
- Guards: Similar to pattern matching, guards help Erlang figure out
which function to call by setting a basic precondition for one or more
parameters. Thus, we could revise our factorial function in a silly way to use
As you can see, this is a silly way to use guards, but I think it gives a good
quick indication of what they do.
- Data Structures: Erlang, for the most part, has a good, rich set
of data structures. Lists are as powerful as they should be, and it has list
comprehensions (which have quickly become one of my favorite Python features).
Tuples work nearly the same as they do in Python as well.
Unlike Python, Erlang features atoms. Atoms, which have no Python equivalent,
consist of any identifier which starts with a lower-case letter or any
single-quoted string. It seems that Erlang's idiom for dictionaries uses tuples
Erlang does (obviously) have variables, but they must start with a capital
letter to be distinguished from atoms. There is also a record type, but I do not
have a good enough understanding of it yet to explain it.
- The Philosophy: The most abstract point here, I think that Erlang
seems to encourage good, readable code. After just a few hours in the language,
I feel comfortable enough to dive into the Erlang httpd server and try to
understand what's going on. Considering that other functional languages have
only given me frustration in this respect, I think it bodes very well for
Erlang to be good in this regard.
- Variable Binding: Variables, once bound in a scope, cannot be
another value in the same scope. I really like Python's binding scheme, where
variables are just names, and may be assigned to refer to anything. However, I
can imagine the variable binding restriction catching a bunch of silly errors.
I haven't used it enough (read: at all) to make a judgment on whether it's
worthwhile or not.
On the upside, it does seem to encourage short functions, which I think is a
good thing. Erlang in general seems to encourage short functions which are used by other objects; I am in the process of studying the Erlang idiom of
supervisors and workers.
- Concurrency: Although it looks neat, I've yet to get in and play
with Erlang's concurrency, so I don't want to render a decision on it.
- No String Type: Let me repeat this for emphasis: There Is No String
Type In Erlang. Arrrggggh! Why would you do this?
A string is treated, you guessed it, as a sequence of ASCII codes in a list.
It's C all over again. The shell tries to "guess" when a list is
actually a string, which is a pain if a list you create just happens to contain
values in the printable ASCII range.
- Error messages: Erlang's error messages are totally undecipherable
for a newbie. Here's what happens when you call a function with the wrong
number of arguments:
- Documentation: Most of the links to documentation on
erlang.org are broken. When you finally do get
to the docs (mysteriously at erlang.se instead of erlang.org), there are some
real gems. When you click on "Complete List of BIFs" (BIF = built-in function)
in the reference manual, you get "For a complete list of BIFs, their
arguments and return values, refer to erlang(3).".
The kicker? When I downloaded and installed Erlang, the man pages either
weren't installed or weren't put in the right place. So, as a newbie, I am left
digging away from the main erlang site just to find out what the f$%$ing
built-in functions are. Not a good sign.
- The; Punctuation. Is, Weird ->: Maybe this is one of the not sure
things, but I'm pretty sure I don't like some of Erlang's punctuation. I don't
mind the '->', but I oftentimes have to look at the docs to figure out whether
I should be using a ';' or a '.' to end a statement. Furthermore, the error
messages, as I've already shown, are less than helpful in guiding you to the
source of the syntax error.
Well, that's it for now. I'm sure I left some stuff out, and I'm sure you
disagree with some of what I've said, so leave me a comment with what you
think or drop me an email.
Overall, I think Erlang has some neat features - especially pattern matching
and guards. Furthermore, if what everyone says is true, its concurrency is fast
and well-designed. Although the lack of proper documentation is a turn-off, I
feel like I'll be able to learn what I need to know from reading the very
readily available code. I'm still going to give it a shot, which is a good