But I still wouldn’t use it on a large projet (and, as a matter of fact, I am not using it on my current OCaml-based large project), for several reasons. I guess I should post my updated views on Ocsigen one of these days.

Then, to build a web application that is highly interactive, you can do really cool stuff with Lwt and the React module. In my case, the web app was handling interaction with an Asterisk server, and was used to automate dialing. Agents would use log into a webpage, connect with their softfone with the Asterisk server, and the webapp was administrating everything, automating calls coming in and out, and handling dynamically with (statically typed) ExtJS the status and outcome of phone calls. And there was another similar webpage for the administrator. All this was fully reactive (An agent event or an Asterisk event or an administrator event usually hd an impact on both Asterisk, the agent’s webpage and the administrator’s webpage), and happening mostly in RAM. The DB was just to memorise what was going on, and was not the heart of a state machine, as is too often the case…

Everything was done in a functional and reactive way. Took me two weeks, only evenings, to develop that.

Somehow, even a Ruby on Rails app is a state machine. Perhaps a “better state machine”, but a state machine nonetheless, in the sense that incoming requests interact with each other by modifying the internal data.

With Ocsigen / Eliom, it’s completely different: it’s a “safely” multithreaded, compiled, application. And that makes all the difference.

Besides, there’s O’Browser, which is an OCaml bytecode machine that is interpreted in Javascript. Meaning that you can run OCaml code in the browser. What would be cool is to have cool javascript libraries such as ExtJS binded to O’Browser: you could use really high abstraction for windowing, etc…

Much has been done for browser-side technology. On server-side, somehow, the “state machine” paradigm has been a hindrance. To some extent, Ocsigen and Eliom fixes that when using high level stuff such as React.

I really think you should have a look at Ocsigen / Eliom / Lwt / React and write another post after that. There are some caveats, and a steep learning curve, but overall, it’s really impressive.

Objective Caml tends to be a “safe” language in that it shields the user from a lot of chaff to concentrate on the relevant concepts, but the downside is that developers are not accustomed to defend themselves against chaff that the language simply cannot shield them from.

Regarding your “what if” question, I don’t think much would happen. The OCaml community is too “silent” (in a good _and_ in a bad sense) to be much of a match against the Ruby, Python, PHP etc. communities.

If you’re accustomed to the buzz and polished presentation of before mentioned communities, you’d have to think that OCaml died somewhere around the mid nineties.