Erlang or Gambit-C/Termite? A practitioner's perspective

Regularly, I need to prototype a new idea that could lead to the development of a new project or product at work. Each time, I have to ask myself: do I prototype it in Scheme or in Erlang (just to make sure it's a throw away ;-)

A few years ago, I would have used Scheme without asking. Now, I would definitely choose Erlang. Why?

1. Syntax. Even if I prefer the Scheme/Lisp syntax for its simplicity and regularity, the Erlang syntax is not that bad and can be easier to grasp for non-Schemers. If your prototype becomes the basis for a new product or internal project (this should not be, but you know how things work in the industry ;-), Erlang may be easier to sell to other developers because of this.
2. Proven platform. Erlang/OTP has been used in a number of large-scale commercial applications and systems. Can you say the same for Gambit-C? Where are the success stories? When selling your project to management, this argument will certainly hit you.
   
3. Commercial support. Erlang/OTP is supported by a team of developers at Ericsson. Gambit-C, although a great piece of software, is the work of a single person. And Marc Feeley is a pretty busy guy. Also, several companies have developed commercial products in Erlang (Nortel, Process One, LShift, to name a few), or provide consulting services in Erlang (like Erlang Consulting).
   
4. SMP support. Gambit-C does not support SMP. This may not be a show-stopper (simply start as many Gambit-C processes as there are cores on your machine). But intra-process communication is way more efficient.
   
5. Mnesia. When you need to add a database to your application, this is a no-brainer in Erlang. Just use Mnesia (unless you have some very specific constraints that Mnesia cannot match). With Gambit-C, you'll need an external RDBMS (like MySQL or PostsgreSQL), and a good library to interface with the database. Using the FFI to integrate the C API of your favorite RDBMS is a no-no! If your code is multi-threaded, all your threads will be blocked during a call to the C API. You don't want this. So you'll need a library that implements the native protocol. That's a lot of work, because you'll want it to be robust and efficient.
   
6. SSH. Erlang comes with a complete SSH server and client. This means you can access your remote Erlang process with SSH and continue to benefit from the REPL.
   
7. OTP. Although I'm still not an OTP expert (I just barely scratched its surface), much of the power of the Erlang platform for the development of reliable, robust distributed applications comes from OTP. Much of it can certainly be implemented in Gambit-C, given enough time and effort, but not everything. Some of its features (like hot code reloading) are built into the runtime system and cannot be easily emulated.
   
8. Yaws. Building a new web app or web service with Yaws is really simply. It is REALLY robust and efficient. With Gambit-C, you have two choices: implement both an HTTP server and an application server yourself, or interface Gambit-C with Apache/mod_lisp. The first option represents a lot of work and requires a lot of expertise to get it right. The second option is a lot easier to implement, but at the expense of administrating another piece in you puzzle.

For these reasons, I would choose Erlang over Gambit-C+Termite for the development of a new scalable and robust distributed application. That being said, Gambit-C is a nice piece of software (in fact my preferred Scheme system), it has a great debugger, and the Scheme Now! project will certainly lead to a number of good portable libraries for Scheme. But from the perspective of an industrial developer, Erlang wins easily.

Your mileage may vary, of course. Feel free to disagree!