Just a quick comment to stress out that Erlang is definitely as well appropriated for rapid prototyping than for production code. It’s a dynamic language, you can build a server really easily and change it’s behavior on the fly. The functional and stateless nature of the language opens new levels of possibilities. Turning the ideas floating in my head into real code remains a fast process (the last one : merging non-destructively two tree structures took me a little bit more than an hour - still, I had to re-read the ‘lists’ and ‘proplists’ modules in order to use some of their useful functions ;).

I have done some interfacing of Erlang and Ruby to make it possible for http://github.com/AlainODea/erlang_code_completion/tree/master to get code completion results to TextMate. I originally used TCP, but found it slow and cumbersome compared to erl_call.

I want to make this point very clearly, erl_call is solid gold. Become acquainted with it if you intend to interface with Erlang easily. It is very fast and provides a good way of interacting with Erlang from other languages lacking a formal integration like JInterface or Erl_Interface.

A Ruby wrapper for erl_call would be very useful. I might bring myself to write such a beast and post it up to GitHub if I get a chance.

Having erl_call in the main bin directory of the Erlang distribution instead of buried inside the erl_interface library would also be useful. You can have erl_call start an Erlang node on demand or execute code from the command-line or STDIN on an existing node using RPC. It is superbly useful. Check out my usage of it in erlang_code_completion to see if it helps solve your problem.

Regarding the syntax, there are certainly some areas of improvement. Becoming more comfortable with the language, I consider this less and less as a real problem.

Overall, the code looks clear and well structured. Most importantly, I was really surprised to see how easy it was to re-enter my code after 1 month off. Even with my short experience with the language I came back in quite smoothly to enhance my prototype (yes, we jumped on the road to the Prod highway ;).

One of the key point is to make the -pattern matching feature- a second nature.

@Rich

I’m going to dedicate an entire post on that matter. I’ll explain how we use Mnesia ( http://www.erlang.org/doc/apps/mnesia/part_frame.html ) and why we are keeping an eye on the CouchDB project (as mentioned in the post, we are already massively using Json as our ‘communication protocol’ between the browser and the server).

In brief, in order to keep as much flexibility as possible in our model and to benefit from the native Erlang data structure, we decided to go without a traditional relational model.

What? No objects, no relational DB? Are you crazy?

As things goes, I’ll explain why it’s not as crazy as it may sound when it comes to play with DB documents and not just tables linked to each other.

Probably the biggest thing that I’d need to wrap my brain around in any case is how, since all your variables/objects/etc. are immutable, do you go about updating the database (or whatever you use as a persistent storage mechanism)? I’ve never seen issues like this discussed in much detail, which is unfortunate since most of the web apps I’ve seen out there at least start off with nothing more than slightly glorified CRUD functionality.