Erlang for web-developers

[ke han]

On Aug 29, 2006, at 8:44 PM, Andrés Valenciano wrote:

> ke han wrote:
>> This does add to the erlang sales pitch problem.
>
> Yes it is a problem, some times when others have used only one tool  
> for
> everything for years and before that another tool for  
> everything...they
> are difficult people to talk to or persuade to change from their  
> comfort
> zone about development.
>
> Most of the things I heard were the same that were thrown to the Rails
> guys: pool of people to work with the "technology", "enterprise
> standard" for web apps, blah blah blah (well, not one thing about
> scalability in this case :) )

yes, rails is much of the time a "pay later" solution.  Frankly, its  
not because rails does anything particularly wrong.   It does many  
things spot on.
There are two negatives with Ruby on Rails...if you allow me to  
grossly oversimplify:

1 - lack of tools for ruby development.  You need a Smalltalk like  
environ to truly understand and explore RoR code.  Rails heavily uses  
"meta-programming".  Ruby mixins are a core of this technique.  Its  
great if you allow the magic to just work for you on things that are  
well documented.  But what happens when you need to push on the  
limits of "convention over configuration"?  ansrwer: you need to  
_know_ what your model, view and controllers are actually inheriting  
at run time.  Along with the obvious lack of a good debugger, Ruby is  
missing the exploratory tools necessary to understand what Rails does  
to your code.

2 - concurrency.  Rails is a "shared nothing" architecture.  This is  
absolutely not the same thing as when we say erlang is a "shared  
nothing" language.  An erlang app shares an enormous amount.  The  
overall effect of an app well coded in erlang can be very efficient  
and scalable.  This is possibly my one and only true criticism of the  
Rails developers.  They are PANSIES!!!!  You heard me.... a solid app  
framework consists of three major things to support the app developer:
	a - declarative programming interface
	b - metadata.  This stuff in its many forms allows the above  
declarative interfaces to do their magic.
	c - concurrency and resource management.  A good app framework  
should bury all issues of concurrency and resource management so that  
an app programmer can write seemingly single threaded code and have  
the app framework worry about what happens when you go from 1 test  
user to 10,000 concurrent real users.
I have written many scalable app frameworks in Smalltalk and Java  
that get all three of the above correct.  Rails completely sidesteps  
the third issue by calling their architecture "shared nothing".  This  
is pansy, weak minded, schoolgirl programming at its worst!!! ;-)   I  
realize Ruby doesn't have a great threading model.  But its not much  
more anemic than a Smalltalk one...and I can tell you that you  
absolutely can make it scale in a single VM!!!  By deferring this  
important issue to high-level HTTP requests which share nothing, you  
lose out on a lot.


>
>
>> 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.
>
> Maybe one thing to do, could be use an Erlang community web site
> answering these question, giving examples of how to integrate Erlang
> with other tools, just like yours.

I will follow the lead taken by so many others and publish a tutorial  
or two in the next two months.  I can tell you though that my way of  
doing things is directly derived from existing tutorials..  I may be  
able to provide yet another concrete example, but some the erlang  
gurus have already published great examples of how to solve these  
problems.  See  Martin Logan's recent thread on tutorial organization.

ke han


>
> Thanks for the answers to my post.
>
> -Andrés