7/26/2008

Erlang Update

I’ve been tearing through Joe Armstrong’s book “Programming Erlang”.  I started reading it about 14 days ago, and I’m already in Chapter 17.  It’s a well written book and a great introduction to the language and some key libraries.

I think the reason I’m working through it at such a rapid clip is that Erlang has captured my imagination.  I’m fascinated by how easy it is to program multi-process applications and distribute those processes across machines.  I’ve written multi-threaded code in Java, Python, and Common Lisp.  Erlang is BY FAR the easiest language for writing MP code.

I can’t wait to finish the book and write my own application. I’m forcing myself to finish the book first because I want to make sure I know all the right tricks before I get started. I think that’s the right idea because I’m now learning about Mnesia and soon I will learn about advanced OTP techniques.

I can’t convey how excited I am by this language/platform. I saw my friend Jeff last night and I bored him to death as I gushed about Erlang. He mentioned that he had recently posted about CouchDB and that it would be cool to develop something social on top of that. Indeed…

7 comments:

Unknown said...

How does Erlang handle providing mutually exclusive access to critical sections?

Every solution I've seen to this problem looks very similar (semaphores). Using semaphores is kinda crude, and puts an ungainly onus on the developer(s) to religiously keep track of, use, and manage said semaphores.

Does Erlang just put wrappers (and the implied overhead) around said low-level mechanisms?

Also, how does it handle inter-thread/process communication and information sharing?

One of the biggest hurdles that the scientific community has had in adopting new fancy interpreted languages is performance - if you're going to bother writing a program that does some hardcore number crunching on a large cluster, where each run could take a week or (sometimes significantly) longer, the overhead implied by an interpreted language usually rules out its use for the bulk of the heavy lifting. Incidentally, that's one reason why Python has seen so much success in scientific computing - the authors of Python went out of their way to make it easy to write C libraries that are directly callable, and then they went on to write very tuned mathematical libraries for common numerical calculations (integration, quadrature, FFT's).

How does Erlang compare?

Tom Pierce said...

Andrew,

Erlang is a shared nothing architecture so there are no issues with updating shared state. There's no reason to mess with locks and semaphores. For low level information, you should look at how the Erlang run time is implemented on the platform you're thinking of.

All process communication is in a client-server pattern. This involves sending direct messages and performing RPC-like calls. The communication mechanism is abstracted away from the user no matter if the processes are on the same run time, separate run times, or separate machines.

My question for you is - how do you define interpreted language? At the point you are calling anything that compiles down to processor instructions, can you consider that interpreted? Python just calling C libraries isn't really the same as doing something dynamic and fancy with Python. You could actually do that with any language that has an FFI.

In addition, Python (like Erlang, Java, Smalltalk, etc.) actually compiles down to byte codes and is executed by the run time.

Now, unlike many other languages, Erlang has been used in real world telephony (and other) applications to achieve incredible uptime in soft real-time systems. So, its computation performance aside, I doubt there would be any issue with assuring that long running calculations complete. That is if you properly architect the solution.

Finally, I'm not an expert on the language. So, if you have deeper questions you should go dig into the language and send out some questions to the community.

Unknown said...

"Erlang is a shared nothing architecture so there are no issues with updating shared state."

Does this mean that it keeps a separate stack for each running thread? I know, in C for example, when you fork() to create a new process, the OS is supposed to copy the entire process frame into a new one. As a result every variable value and function pointer gets duplicated in memory. This is fine for creating a new independent process. Threads, on the other hand, share stack space, so you can have multiple concurrent threads sharing variables (keeping memory overhead down).

It sounds like Erlang doesn't support the notion of sharing stack space by forcing each executing "thread" to have its own memory.

That neatly skirts some of the issues associated with concurrent programming, although it does imply some potentially hefty memory overhead. Am I off base on this?

I found a link you might find interesting: http://jkndrkn.livejournal.com/205249.html

It compares the performance of Erlang with C + MPI for cluster computing. It was the result of one guy working on it for a semester, so it's not groundbreaking, but it's got some nice charts and graphs.

Tom Pierce said...

Very nice link. I will tell you I would rather try to do MP in Erlang than I would C with MPI. However, I haven't written C in 7 years. I think having a dynamic garbage collected language on your side would really improve your programmer productivity.

I'm not sure how the virtual machine would map its work onto OS threads. That would be an interesting thing to look into.

I'm not sure what application you might have in mind. In my opinion, Erlang should be applicable for a broad range of MP applications. It would win any time you place a higher value on programmer time and program accuracy. In my experience multi-threaded/multi-process programming on other platforms is very difficult and prone to difficult bugs.

Unknown said...

"I'm not sure what application you might have in mind."

And ultimately, neither do I, so take all this rambling with a healthy dose of NaCl.

When I took Programming Languages at the graduate level I was exposed to several languages from a number of paradigms (Disclaimer: Erlang was not one of them). But one thing that seemed like a deal-breaker to me was most of the languages we looked at didn't have any modern GUI libraries (like QT or GTK), didn't have OpenGL or DirectX bindings, and weren't suited for use as a server-side web scripting language. That seems to suggest that they are suited to simple console applications and back-end number crunching.

But it gets better - for back-end number crunching, C / C++ does it more efficiently, Matlab does it more conveniently, and if you are going to distribute it on a cluster the differences become more pronounced.

In the time that I set aside as 'spare', I like learning new things - but to learn a new language, I need a motivating reason.

Why should I learn Erlang? What can it do that any of the languages I know already can't do better? (that list includes: C, C++, Java, C#, PHP, Ruby[onRails], Javascript, ColdFusion)

If the answer is "It has elegant SMP capabilities", that's a pretty good reason, but it's less of a good reason if it doesn't perform well in contexts where you're likely to want the kind of performance that SMP can give you. Note that I said "less of a good reason", because it doesn't rule it out for reasons you mentioned.

Perhaps we could meet for lunch one day, and you could show me some code and make me a believer. I'd buy, for once (I figure I owe you a few lunches anyway).

Tom Pierce said...

Andrew,

My disclaimer is that I have a computer language fetish. I usually tackle a new one about every 1-2 years. I've learned and forgotten several, and there are still more I want to tackle one day (Haskell, OCaml, Oz, and Lua - I'm coming for you. You've been warned.) So, I need very little motivation to learn a new language and if it's one that tackles a problem that is crappy to solve in other platforms - so much the better.

I believe languages are like power tools. You have to pick the right one for the job. If you need to have a really great UI, then I would suggest doing something that has great UI libraries or bindings on your platform of choice. If you have to have something that has great performance on a single processor, I would suggest something that compiles down tightly and has a great optimizer. If you want to slam a web site together quickly, I would look for a platform (not just a language) that has great libraries, templating, and generates alot of code for you.

However, I think most of the time you have to strike a balance. Problems are rarely 1 dimensional. Furthermore, you have to decide what you value. How much do you want to spend in programmer time to solve a particular problem. For example, if you are willing to spend alot of money to make your great looking UI application the most performant on the planet - by all means write it in C. If you value programmer time, time to market, and longer term maintenance, you should pick a language that is much more programmer friendly than C.

So, why would I pick Erlang? I would pick Erlang in an application that needs to scale, that I would want to take advantage of MP, where I value programmer time, where I have a smaller value on single core performance, and where I don't care about finding commodity programmers to support the application. I think Erlang would be ideal for a web based application using ErlyWeb or as a web services call from another platform that needs to Internet scale. I think it would also be great for applications that are compute intensive and must track things in real time, but be highly flexible and maintainable - like a MMOG.

All this is of course my opinion and I have yet to write my first real application in Erlang - so you're catching me at a well educated point. :-)

We should definitely do lunch or at least a phone call. I have an idea to bounce off of you.

Bob N4HY said...

If you liked Armstrong's book, you are going to really like the new O'Reilly Erlang book. It is, in my opinion, a much better book, with a better approach and more relevant examples to today's needs. For example, discovery of other nodes and services is covered much more completely in the new O'Reilly book and very poorly indeed in the Armstrong book.