Erlang for web-developers

[ke han]

On Aug 29, 2006, at 10:55 AM, Andrés Valenciano wrote:

> Dmitrii Dimandt wrote:
>> I think that in order to sell Erlang to web developers, we need to  
>> focus
>> exactly on the things that can be "branched off". Because telecom  
>> stuff
>> is interesting, but it also is scary. What else can we lure web
>> developers with?
>
> I am new guy in this Erlang block after years of Java, some Python  
> and a
> year of Ruby ( and others before those 3).
>
> I am very interested in Erlang for web development but at this point
> some things are missing for me, those are the more "trivial" things  
> like
> PDF generation, charts, all these other features that some web
> applications needs that are not as interesting as all the Erlang
> strengths but some times needed.

This does add to the erlang sales pitch problem.
I think the best way to approach this issue is to think of erlang as  
your central command and control center.  You can spawn an external  
process to handle non-erlang tools like full text search, image  
manipulation, SMS gateway, etc...  You can do this cheap and easy by  
just spawning an external process (think of the CGI paradigm) or have  
the extrenal process connect back to an erlang socket server and keep  
the external resource alive (think FCGI).  Once you see how easy it  
is to create ad-hoc erlang socket servers to wrapper external tools,  
I think your fears of not having feature X as a native erlang lib  
will dissipate.
The sales pitch for this structure is to say you can choose best of  
breed for any feature you might encounter as opposed to being stuck  
with the "Cold Fusion choice or much harder choice" for feature X.
I am taking this approach for my full text search needs by using  
lucene (Java).  I get the best of both tools with very little trouble  
for using multiple technologies.

I am also using the erlang custom socket server approach for a custom  
C++ server which needs to handle authentication and authorization.   
My C++ deamon is a fast single threaded socket relay server which  
could get its auth info via a call to MySQL which would be a shared  
data source along with the erlang web app.  Although relying on a  
central db is a nice tried and true method for shared auth info, it  
means that my simple C++ deamon must add threaded handlers for making  
the MySQL calls...if not, my fast socket relay will bottleneck all  
the existing packets for existing connections while it handles auth  
for each new connection.  My solution is to let the C++ deamon  
connect to a custom auth server running in the same erlang vm as my  
yaws web app.  This gives me much faster access to the auth info than  
making a SQL query and its a fast enough solution that I don't need  
to introduce threading in my C++ deamon.

The reason for elaborating on this example is to show that any IT  
solution which gets complex enough should make best of breed  
choices.  There exists a  "one language must have it all" approach  
which makes many decision makers feel comfortable.  I think this  
"comfort" is overstated and limits your horizon when adding  
unforeseen new features.

ke han

>
> For example, I am in the starting process for a new project (in my day
> job), a web project, that has a SMS related service and I was really
> excited about it because I thought I could use Erlang there but then
> this other guy with Cold Fusion experience wants to use that  
> product for
> the project, which gives the web server, the not-so-interesting things
> like PDF, Flash, etc and an SMPP implementation all in the same  
> package.
>
> Is that one a lost battle in my case?
>
>
> -Andrés
>
>
>