Evaluating High-Level Distributed Language Constructs

I saw this mentioned by one of the authors on the erlang-questions mailing list:

The paper investigates the impact of high level distributed programming language constructs on the engineering of realistic software components. Based on reengineering two non-trivial telecoms components, we compare two high-level distributed functional languages, Erlang and GdH, with conventional distributed technologies C++/CORBA and C++/UDP.

GdH = Glasgow distributed Haskell.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Apples to PCs comparison?

I liked the paper and am a big fan of Erlang.

However I'm not sure it is entirely fair to compare a language (C++) to a combination of Erlang plus a standard server architecture, the Erlang runtime. The latter prescribes a way of error handling ("don't") and gives you automatic serialization, for example, both of which are architectural choices they apparently chose not to exercise in the C++ implementation (I find it surprising, for example, that 22% of the code is devoted to communication (table 4)).

What if we chose the following patterns for a C++ server architecture?

  • All messages are simple structs (not objects), and serialization
    and toXML() is code-gen'd? After all, Erlang doesn't bother with
    encapsulation either (you can't pattern match otherwise)
  • Use coroutines, making sure that all messages between tasks are
    copied. After all, Erlang does that and it is either good enough
    performance-wise or the benefits of isolation are worth it. Note
    that one would need a fraction of the tasks that one would require
    in Erlang, because an Erlang process is often used as an object to
    maintain state.
  • Forget CORBA or any other on-the-wire portable approach.
    Erlang's native messaging doesn't bother about versioning or
    exchanging messages with other systems either. Forget about having
    an elaborate naming service that understands LDAP or any
    other standard.
  • Have a standard memory management convention and not be afraid
    of copies (to begin with). Of course, this doesn't compare to
    GC, but I believe that much of C++ programming style is crippled
    by enormous premature optimization and concomitant defensive programming.


Indeed, the difference being

Indeed, the difference being that you have more control over the "machine" state than you do in Erlang, which might enable some application-specific performance tweak (read: hack). Not recommended I'm sure, but I'm sure it's done in practice. :-)