Thrift, while not dynamic in the classic sense, seems to do a good job at creating extensible interfaces with a defined but flexible contract (IDL) that are usable in both dynamic and static languages. All in all, from what I’ve seen so far, it’s a pragmatic compromise weighting the different forces in the right way (IMHO, anyway).

Unlike Hessian, it also doesn’t favour one language. Hessian does so for Java, all the clients for other languages are fig leafs.

I’m primarily a Python programmer getting my feet wet with projects combining Python and Erlang. Probably the best way to get the gist of Erlang is to read/skim Joe Armstrong’s thesis: http://www.erlang.org/download/armstrongthesis2003.pdf.

I’ve dabbled in Scheme, Common Lisp, Ada, and other languages, but Erlang is the only language I’ve decided to actually use for real work in the past 10 years other than Python. In my experience, languages like Python and Erlang complement each other. Neither language does everything. It’s important to remember that all languages have design trade-offs due to their emphasis.

Erlang is most definitely worth learning, but not because it is “better” than favorite language X, or because it is designed to completely replace your favorite language, but because it made trade-offs that other languages didn’t, that solve the big difficult problems of software that are very difficult or impossible to fully solve in other languages without making the same extreme trade-offs. Let Erlang make the trade-offs so your other language doesn’t have to. :-) A realistic and common approach is to combine Erlang with other languages, like Python.

Here is a comparison of some of the trade-offs and reasoning behind the different languages. (For more details on the Erlang side, please read the thesis PDF.)

Python and concurrency: Python has the GIL to make it easier for C to interact with Python (from what I’ve heard). The GIL could be removed, but supposedly writing C towards Python would have been made more complicated. The advantage of the GIL is that Python is a great glue language as a result. The disadvantage is reduced ability to take advantage of threads. But I think Python got it right when deciding to go multi-process as a solution, and Erlang also agrees on this design philosophy of using processes. :-)

Erlang and concurrency: People should keep in mind the context in which Erlang was created. It was for telecoms, where the system must be reliable and never go down, while also supporting a high amount of reliable concurrency. Deferring concurrency to OS-level threads or OS-level processes wouldn’t work, either because they’re too slow, or because shared-state is unreliable. Deferring to the OS also can make concurrency inconvenient or sacrifice portability, or at least consistency in performance across platforms. The conclusion was to create lightweight, runtime-level processes. These are not the same as many tasklet, coroutine, pseudo-thread, etc. implementations. The processes must be truly concurrent, not cooperative, and they cannot share state. This separation adds to the additional goal of fault isolation. Processes aren’t just a feature, they are the unit-of-work much like how objects are for pure object-oriented languages. Processes communicate through messages. Supposedly, message-passing was a key concept of object-orientation in Smalltalk that was lost in C++, Java, etc. So, processes are analogous to objects (or you can consider them objects from a certain point of view), except they are naturally concurrent and provide more physical separation than multiple objects within the same process in other languages.

Python and libraries: Python readily binds to C/C++ libraries, and this is convenient. But what happens if that library itself has a serious bug? I’ve personally experienced times when (especially a C++ library, such as earlier versions of wxPython or beta-quality 3D engines) would crash Python, even though Python itself is stable. The trade-off is that Python readily talks to all sorts of libraries easily, but risks being at the mercy of failures from those libraries. As another example, try using ctypes where the C library is coded badly. For many people, the convenience is worth the risk. For others where the system must not go down (e.g. telecoms, mission-critical servers, control apps), the convenience isn’t worth the risk. It’s a different emphasis/trade-off.

Erlang and libraries: To talk to other languages, you use a “port” in Erlang, where the external language is a separate process that acts as an Erlang process from Erlang’s point of view. The trade-off is that you get fault isolation (which is an explicit goal of Erlang, but not an explicit goal of Python, although desirable) at the expense of some extra work. External code won’t crash Erlang if they’re utilized as ports.

Python error handling: Python uses error-trapping with try/except, like other languages that have try/catch, etc. Because a process is not the de facto unit-of-work for Python, it’s natural that error handling is performed within the same process (by default). Although, you could probably act on the exception with a distributed call, the error-trapping is always essentially performed in the same process.

Erlang error handling: Fault-tolerance is an explicit Erlang goal. That means guarding against hardware failure, and not just software exceptions. The only way to guard against hardware failure is through distributed programming, i.e. redundancy and fail-over. This is more than just watching a heart-beat, it can involve any sort of error or exception. The requirement that the error-trapping occurs in the same process as the error makes distributed programming more difficult or less robust. Often the process can’t continue and shouldn’t even try, and so the sensible thing to do is to detect that is the case, crash the process, and restart the process or groups of related processes, where this might even be done from a non-local supervisory process. The exact semantics of how this is done is subtly different than other languages. Maybe you could do it, but not without a lot of work. Technically you can do anything in C that you could do in Python, but the point is to use the best tool for the job. For fault-tolerant sorts of things, Erlang is most likely the best tool for the job.

There is much more than this (behaviors, supervision hierarchies, etc.) but by now it should be apparent that Python and Erlang do their jobs well, but they were meant for different jobs. But there is no reason that such jobs aren’t complementary. For example, I’d looked at Twisted too, and it is so foreign from most normal Python code that you might as well learn another language. Especially because it doesn’t have the built-in facilities for distributed message passing at the language level, distributed error handling, share-nothing semantics, etc.

If you want one reason to learn Erlang, it is this: no other language has seemed to solve the problem of reliable concurrency anywhere near as well. And that is kind of important. Erlang seems to be the only language that comes close to readily scaling linearly in performance with multi-core and distributed. Little things like pattern matching and single-assignment are part of the goal for reliability, but in themselves aren’t the whole point.

Oddly, when people think about this second problem they seem to ignore the possibility that instead of changing runtimes dramatically they could just fix their build process. (The challenging part is that fixing the build process in this way usually involves pushing complexity out of the build and up into the language, framework, and application — but it seems to be worth it.)

Yes, I think that’s the current big challenge that is being ignored by the continuing excitement over “many languages in a single VM”. We need better ways to do “many languages in many VMs on many nodes”.

Primarily that seems like a job for HTTP and XMPP plus some JSON/XHTML conventions plus some management/operations capabilities.

“Maintaining anything is a problem…”

I assume I can quote you on that… ;^/

Maintaining a heterogeneous system is also difficult, but a separate problem. Maintaining anything is a problem, it’s just one that happens to scale O(n) for n kinds of systems.

Yeah. I don’t know that I was actually thinking about anything specific, but this is essentially it.

The “application specific” parts of a web application seem easy in Python, Ruby, etc. The “system specific” parts seem fairly easy in Erlang. What would be great would be the ability to integrate these two easily.

So rather than a Django application running in all Python (I assume — don’t know much about Django) instead the distributed, supervisory, scale-outing stuff in Erlang and the app per se in Python. But the Python developer does not have to know that the system stuff is in Erlang.

And the system stuff in Erlang could just as well be running apps in Python as well as Ruby or who-knows-what.

To work with MySQL you have an integration protocol. Same with Erlang and other languages. Although it could be easier.

Another example I’ve dealt with in the past: the CLIPS rules engine, and Python has a nice integration: PyCLIPS. I’d like to have a farm of rules engines, talk to them through some scalable, distributed, supervisable mechanism just like what Erlang/OTP provides. But talk to them as Python/PyCLIPS “services”.

It’s very “do-able” but fairly ad hoc. Especially if part of the system is in Ruby, part is in Erlang, and part is in Python (and part in CLIPS (lisp, if no using PyCLIPS)).

I know enough Twisted to know that’s the wrong way to write web applications. Maybe it’s the right way to write servers that interact directly with sockets. Maybe. I don’t know much Twisted at all, yet I feel pretty confident about my opinion. Erlang takes a somewhat different approach, and obviously has the language support to back that approach where Twisted does not. But while I know less about Erlang than I do about Twisted — and I should rectify that — I can’t help but notice a lack of people claiming Erlang is the Complete Package, or even anywhere close to it.

So… what should I expect to find out, ultimately? That Erlang is super-awesome and I’m going to stop using anything else? That share-nothing is nice, but in order to get it I’ll need to use something more like CGI (ala App Engine)? That some hybrid approach is workable, using Erlang for things like a database (e.g., Couch) but writing all my code using traditional concurrency techniques? If the last one is the case (I guess what Patrick is proposing) then… do I need to care about Erlang? If I deploy CouchDB and use it from Python, what should I care what CouchDB implemented in? I don’t worry a great deal about what MySQL is written in.

Messaging and pattern matching in Erlang are deeply intertwined, i.e. “selective pattern-based receive”. If you just accept messages over various pipes and you just pattern match on various language data structures, you still don’t obtain the benefits of an intertwined mechanism for pattern matching within the “per thread” (shared nothing thread in Erlang) mailbox.

Erlang is subtly, specially simple in its own way, just as Python’s various object, meta, syntactical foo makes it expressive in its own way. What we really need are simple, efficient ways to interact between Erlang, Python, and other systems, not necessarily, if ever, running in the same OS process. We need to easily spin each of these things up to do their own work and use each other.

Such a mechanism exists for Python and Java and C to interact with Erlang, but we need more general foo.