Erlang killer app?,
Sun Jul 21 01:31:39 CEST 2002
> Alex, which bits do you imagine would really use
> Erlangs strengths, which bits would need to be
> implemented in something else? How did you hear about
I have been on a search for "a better way" to write software for several years. I discovered the
"functional" style about two years ago and started with Common Lisp, then Scheme and wrote some
interesting stuff in (PLT) Scheme and (Franz) Common Lisp realizing significant productivity gains.
I also looked into Haskell (and Clean) and SML (and Miranda) and CAML.
Of all of these only Franz Common Lisp has a broad enough set of capabilities for my world (see
previous message on this thread), but it is outrageously expensive! ($6000 per seat for development
and $20,000 per server for deployment of the app!)
PLT Scheme comes close, but "academic, as time permits" support is not a good bet for the commercial
systems I write.
"Libraries" for the ML languages are sparse (as relates to my world). Though interestingly things
are starting to happen with .NET (which opens up huge libraries). There are now an early versions of
SML.NET and also CAML.Net (called F#).
I found Erlang just a few months ago as I continued to search. It is "fairly" complete for what I
want and commercial enough (but I am still very much novice in Erlang).
I like the Erlang language (functional, pattern matching, ...) and the natural distributed nature of
it. I have re-written my Lisp/Scheme pattern generators in Erlang and they are more elegant now.
Erlang can connect to RDBMSs (only ODBC, but I can live with that) and that is essential in my work.
A Web Server (yaws?) as distributed application server is important building scalable applications
as well as for Web Services (SOAP/XML), and of course as web server for browser based UI. I have not
discovered the level of support for generating HTML, dealing with XML (and SOAP) yet.
>From what I have seen so far, the UI creation part is sadly lacking in Erlang. I just mentioned HTML
for browsers, and for "thick" clients (for a more interesting and productive UI) it appears that
tcl/tk is the answer. My first experiments there had the first window take 12 seconds to open (using
an example from the docs)! And I cannot see how to work with "interesting" UI widgets - grids like
ComponentOne and Infragistics. It would be fine if interop were "easy" with (perhaps) .NET? (or
Java?) for the UI part. Web Services might solve that -- I write the UI in C# or Java -- that would
I am not sure if it is going to be difficult in Erlang (without (.NET, Java) interop), but I need
"Message Queuing" (the reliable, transactional delivery of arbitrary messages over a network, with
alternate routing in case of failure). MQ does exist in COM and that is supported by Erlang (I
I ramble, sorry.
More information about the erlang-questions