Erlang for web-developers
Tue Aug 29 17:28:35 CEST 2006
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
> everything for years and before that another tool for
> are difficult people to talk to or persuade to change from their
> 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
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
> 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.
> Thanks for the answers to my post.
More information about the erlang-questions