Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Tutorial On Building Robust Servers In Erlang 19

mvw writes "Wanna go beyond Java, Perl, or Python? Joe Armstrong has published a nice tutorial on implementing robust servers in the functional concurrent Erlang language. Here is the link."
This discussion has been archived. No new comments can be posted.

Tutorial On Building Robust Servers In Erlang

Comments Filter:
  • Why Erlang? (Score:2, Insightful)

    by StressedEd ( 308123 )
    Does anyone have a (one line) compelling reason why Erlang is preferable to (say Perl, Java or even good ol' C(*))?

    Cynically I look at this and think "great, another programming language that allows me to print "hello world" in a more obtuse manner".

    I'm quite happy to be put straight on this, from any hardend Erlang users.

    (*) Ok, ignoring the point of buffer overflows, etc.

    • Re:Why Erlang? (Score:2, Informative)

      by Anonymous Coward
      Erlang has great concurrency. It can handle thousands of multiple processes
    • Re:Why Erlang? (Score:4, Informative)

      by whee ( 36911 ) on Wednesday February 05, 2003 @04:26PM (#5234416)
      Well, besides the obvious concurrency advantage (need 200000 processes? no problem!), there's things like hot swapping of code, behaviors for common design patterns (servers, event handling, supervisors), bundled database written in Erlang, and other things like that.

      Writing a robust program in Erlang is extremely simple by using supervisors and following design principles like these [erlang.org]. For example, my Erlang IRC bot is near impossible to completely crash. If the server connection dies, there's a supervisor that'll keep trying to get it back up; All the while the other processes of the bot have no idea there's no connection -- they don't need to know. If I've written a faulty module and the code misbehaves, only that single process is affected. If possible, a process that has crashed will be automatically restarted and operations resume as if nothing had happened.

      Hot-swapping of code allows me to debug the bot without restarting it. If I discover a bug in the irc parsing routines, I simply fix it in the code, recompile, and reload the offending module -- while the bot is running. The new code replaces the old, and it just works.

      There's plenty more, but I would suggest checking Erlang's website [erlang.org] and reading the FAQ and examples. Oh, and here's [www.sics.se] a nifty benchmark :)

      • supervisors and following design principles like these

        Hmmm.. I like the idea behind the "supervision tree". Why is that not possible to implement in other languages?

        Well, besides the obvious concurrency advantage (need 200000 processes? no problem!)

        Is that similar to the implementation of concurrency in Ada?

        I discover a bug in the irc parsing routines, I simply fix it in the code, recompile, and reload the offending module -- while the bot is running.

        Now that is very interesting! Hmmm.. I can see where this would be very useful in a server environment.

        Thanks for your explanation...

        • Re:Why Erlang? (Score:3, Insightful)

          by whee ( 36911 )
          Hmmm.. I like the idea behind the "supervision tree". Why is that not possible to implement in other languages?
          It may or may not be possible to implement, but chances are something like it isn't distributed with the language. The supervisor structure distributed with Erlang is well-tested, robust, and quite usable.
          Is that similar to the implementation of concurrency in Ada?
          I'm not familiar with concurrency in Ada. In Erlang, processes are extremely lightweight and communicate via message passing. The processes themselves are done in the runtime, so there are no limits imposed by the OS (besides system resources, of course). With a shared heap, even the memory requirements are extremely low (compared to Java or C, for instance).
          • Is that similar to the implementation of concurrency in Ada?

            I'm not familiar with concurrency in Ada. In Erlang, processes are extremely lightweight and communicate via message passing. The processes themselves are done in the runtime, so there are no limits imposed by the OS (besides system resources, of course). With a shared heap, even the memory requirements are extremely low (compared to Java or C, for instance).

            As an Ada programmer I can tell you that it depends on your compiler. The Ada compiler I use GNAT [gnat.com] uses the OS resources to map Ada tasks to threads so they are as light as system threads. The Rational Ada 83 compiler had its own thread library I believe (I don't care to go looking for it). I'm too lazy to check right now but I believe the Ada RM [adahome.com] leaves it open to the implementation as to whether Ada tasks reflect OS based entities or not.

      • Wow , you can reload modules while a program is *running*?! Man , why can't you do that in other programming languages ... oh wait , you can , they're called .dll's in windows and shared objects (.so) in unix and you can write them in whatever language you like (usually C/C++). BFD.
        • I'll admit, I don't know much about the details of shared library loading and reloading; That said, I doubt it's anywhere near as effective as Erlang's hot-swapping [ericsson.com] of running code.

          For one, Erlang handles code replacement in the runtime -- no dependence on the underlying OS implementation. What happens when you try to reload a shared library with the same symbols? What if module A is in the middle of module B's routines, while you reload B's shared library? What if you just changed a data structure in a few modules and need a system-wide reload? I sure wouldn't want to have to handle synchronising that in C or C++.

          The mechanisms to handle these situations are already present in Erlang; There's no need to reinvent the wheel here.

          • You can do anything you like with a language thats interpreted. You'd probably find that if Erlang was compiled (fully compiled, not just to run on a VM) those facilities would disappear because then the program would have to rely on the underlying OS just like any other binary.
            • Sure you can, and I can go rewrite the Linux kernel in Haskell. There just aren't any other languages with these facilities.
        • It's really not a question of COULD be done. It COULD be done in many languages.

          The point is it HAS been done in Erlang as a standard part of the language.

    • Re:Why Erlang? (Score:1, Informative)

      by Anonymous Coward
      In one line - easy Because the code is shorter, clearer and more beautiful - because segmentation violations cannot happen - because buffer overflows cannot happen - because processes in Erlang are much lighter weight than in Java/C/... - because you will have finished the Erlang program before you have even started wondering how to do it in C ...
  • WTF is Erlang? (Score:3, Informative)

    by Anonymous Coward on Wednesday February 05, 2003 @03:16PM (#5233816)
    The FAQ says:

    Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson.

  • hmm (Score:3, Informative)

    by hfastedge ( 542013 ) on Wednesday February 05, 2003 @03:21PM (#5233889) Homepage Journal
    although i have just learned about erlang. i went to the trusty computer language shootout, and behold, it covered erlang!

    http://www.bagley.org/~doug/shootout/lang/erlang/ [bagley.org]

    This doesnt mean much as far more qualitative arguments exist. You can also browse over the code. :-)
  • Erlang pong (Score:2, Informative)

    by Anonymous Coward
    As part of a class assignment I once had to create a distributed pong game in Erlang. I like the language and I think it will be appropriate for what they are talking about.
  • Sorry folks, the link has moved in the meantime to

    http://www.sics.se/~joe/tutorials/robust_server/ro bust_server.html [www.sics.se].

    Regards,
    Marc

"All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants

Working...