Erlang for web-developers

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Erlang for web-developers

Dmitrii Dimandt
I couldn't leave a reply to Yariv's post because of some error I kept on receiving, so I decided to respond here.

I think that besides "erlang-telecom-erlang-telecom" web developers should also be told this:

- Mnesia is a nice database for small amounts of data - 4-8 GB, not more :))) (am I correct on this estimate?)

- Quite a lot of things can be parallelized in web development. Most notably, logging and post-process actions:

-- Once you do an action you can spawn a separate logging process and return to the user immediately
-- Once you accept all data (most notably, image files), you can spawn separate processes to do whatever with the data at hand (scale, crop, rotate, move to a different folder etc. etc.) and return to the user immediately

Many web developers don't even understand that this, indeed, is possible.

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?
Reply | Threaded
Open this post in threaded view
|

RE: Erlang for web-developers

Juhani Ränkimies
Is anyone implementing bayeux
(http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt)?
Or something similiar?

I think web developers would find that quite interesting. I do.

> -------- Original Message --------
> Subject: Erlang for web-developers
> From: "Dmitrii Dimandt" <[hidden email]>
> Date: Mon, August 28, 2006 10:50 am
> To: "Erlang-Questions Mailing List" <[hidden email]>
>
> I couldn't leave a reply to Yariv's post because of some error I kept on receiving, so I decided to respond here.
>
> I think that besides "erlang-telecom-erlang-telecom" web developers should also be told this:
>
> - Mnesia is a nice database for small amounts of data - 4-8 GB, not more :))) (am I correct on this estimate?)
>
> - Quite a lot of things can be parallelized in web development. Most notably, logging and post-process actions:
>
> -- Once you do an action you can spawn a separate logging process and return to the user immediately
> -- Once you accept all data (most notably, image files), you can spawn separate processes to do whatever with the data at hand (scale, crop, rotate, move to a different folder etc. etc.) and return to the user immediately
>
> Many web developers don't even understand that this, indeed, is possible.
>
> 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?
>  

Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Roberto Saccon
yes, me. I am trying to implement flash as preferred transport type
(if flashplayer is installed). In that case it will also be possible
to stream audio/video in sync with the COMET messages. It's currently
part of a web app I am working on, but later I will extract the
generic parts and release them as open source.

regards
--
Roberto Saccon
Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

yarivvv
In reply to this post by Dmitrii Dimandt
Hi Dmitri,

On 8/28/06, Dmitrii Dimandt <[hidden email]> wrote:
> I couldn't leave a reply to Yariv's post because of some error I kept on
> receiving, so I decided to respond here.

Thanks for the response. Apparently Rails has reached its scalability
limits once my blog has reached a few thousand visitors, and now it
experiences intermittent errors that I'm at a loss to fix. Very
annoying.

Sometimes even sudoing as root and killing all the OS processes that
Lighttpd spawns for handling the fastcgi requests and then restarting
Lighttpd doesn't help, and the only recourse is to physically reboot
the server.

I didn't want to write about it in my blog because I didn't want
people to think I'm taking cheap shots at Rails, but after my
experience with typo, I'd be crazy to use Rails to rather than Yaws to
build a real app :)

>
> I think that besides "erlang-telecom-erlang-telecom" web developers should
> also be told this:

Yes, there are many things they should be told about Erlang, on many
of which I'm far from an expert (hint: I woulnd't mind getting some
help ;) ). I try to keep each article relatively short so people can
consume Erlang knowledge in bite-sized portions without being
overwhelmed.

>
> - Mnesia is a nice database for small amounts of data - 4-8 GB, not more
> :))) (am I correct on this estimate?)

I think Mnesia could also be a killer app for a distributed webapp
session store. I just haven't used it like that yet.

>
> - Quite a lot of things can be parallelized in web development. Most
> notably, logging and post-process actions:

Good point.

>
> -- Once you do an action you can spawn a separate logging process and return
> to the user immediately

Somebody has also mentioned on the erlyaws list you can keep a process
for each user to get the effect of a continuation, only much more
elegantly. I haven't tried it, though.

> -- Once you accept all data (most notably, image files), you can spawn
> separate processes to do whatever with the data at hand (scale, crop,
> rotate, move to a different folder etc. etc.) and return to the user
> immediately

Again, good point.

>
> Many web developers don't even understand that this, indeed, is possible.
>
> 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?
>

Thanks for the feedback. You've given me more good answers I can give
to people who ask me "Why use Erlang? After all, I don't need to use
concurrency in my webapp."

Thanks,
Yariv
Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Joel Reymont

On Aug 28, 2006, at 1:47 PM, Yariv Sadan wrote:

> Thanks for the response. Apparently Rails has reached its scalability
> limits once my blog has reached a few thousand visitors, and now it
> experiences intermittent errors that I'm at a loss to fix. Very
> annoying.

Make sure it's not your hosting provider. I get reddit people too  
from time to time and my blog used to suck when I was with Dreamhost.  
I moved to Planet Argon and my site is much better now. I do run Typo.

Many people are running Typo and getting thousands of hits. Of course  
they don't try to handle all their load on a single box.

--
http://wagerlabs.com/





Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Alex Arnon


On 8/28/06, Joel Reymont <[hidden email] > wrote:

On Aug 28, 2006, at 1:47 PM, Yariv Sadan wrote:

> Thanks for the response. Apparently Rails has reached its scalability
> limits once my blog has reached a few thousand visitors, and now it
> experiences intermittent errors that I'm at a loss to fix. Very
> annoying.

Make sure it's not your hosting provider. I get reddit people too
from time to time and my blog used to suck when I was with Dreamhost.
I moved to Planet Argon and my site is much better now. I do run Typo.

Many people are running Typo and getting thousands of hits. Of course
they don't try to handle all their load on a single box.

--
<a href="http://wagerlabs.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://wagerlabs.com/

I understand that quite a few high-volume sites use Rails - Penny Arcade, for example. So checking the host or configuration would make sense, particularly if you get

Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

ke han
In reply to this post by Joel Reymont

On Aug 28, 2006, at 9:41 PM, Joel Reymont wrote:

>
> On Aug 28, 2006, at 1:47 PM, Yariv Sadan wrote:
>
>> Thanks for the response. Apparently Rails has reached its scalability
>> limits once my blog has reached a few thousand visitors, and now it
>> experiences intermittent errors that I'm at a loss to fix. Very
>> annoying.
>
> Make sure it's not your hosting provider. I get reddit people too  
> from time to time and my blog used to suck when I was with  
> Dreamhost. I moved to Planet Argon and my site is much better now.  
> I do run Typo.
>
> Many people are running Typo and getting thousands of hits. Of  
> course they don't try to handle all their load on a single box.

exactly the point....without lots of carefully managed and well  
configured components, an app built on something like Rails won't be  
reliable when you get spiked.

The recommended approaches to scaling with rails do work, but there  
are _lots_ of parts to install and configure just so.  Companies like  
textdrive and the soon to be released railsbase are obviously hoping  
to cash in on solving this problem.  Within the next year or so, you  
should be able to host your Rails app on a grid like hosting system  
and draw from a well configured and managed "mega-host".  FYI, it  
looks as though the textdrive (maybe railsbase) folks will be running  
this new grid on Niagra servers.  I have no special inside knowledge,  
I just try to keep up with what info is available...but I"m pretty  
sure on all this speculation.
So if your app fits into the well defined sweetspot of what Rails  
does well, you will be able to publish your app and pay for resource  
usage like any other well managed utility instead of owning and  
managing your own server cluster.

But if you want an app that doesn't fit into the Rails sweet spot or  
if you need it today or if you need to mitigate lower operations  
costs than these new utility like hosting services might  
provide....well your back to square one ;-).

I spent about 2 months working with Rails this year.  I'm back to  
redoing the app in erlang.

ke han


>
> --
> http://wagerlabs.com/
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Joel Reymont

On Aug 28, 2006, at 7:15 PM, ke han wrote:

> I spent about 2 months working with Rails this year.  I'm back to  
> redoing the app in erlang.

What was the trouble with Rails? We are using Rails where I contract  
since I could not convince the powers that be to use Erlang. It seems  
to be working so far.

        Thanks, Joel

--
http://wagerlabs.com/





Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

yarivvv
Joel,

There's an interesting 4-article series about the difficulties of
scaling a high volume Rails app here:
http://poocs.net/articles/2006/03/13/the-adventures-of-scaling-stage-1.

It would be interesting for you to read.

From these articles, it sounds like scaling Rails is quite hard, and
when you reach certain bottlenecks, it's hard to diagnose where they
are.

On my blog, I'm occasionally having issues sometimes when users can't
submit comments. When I try to restart lighttpd, I get runaway Ruby
processes that don't shut down. Even "sudo killall -kill ruby" doesn't
work. The only option is to do "su" and then "kill -kill PID" for each
Ruby process. Sometimes doing this and then restarting Lighttpd works,
but sometimes my only choice is to restart the server.

This might be something specific to my environment (I have a virtual
server). I can't say conclusively whether this is a problem with Rails
or if I messed up the setup somehow. I have a recent version of Rails
and Typo.

Best,
Yariv

>
> What was the trouble with Rails? We are using Rails where I contract
> since I could not convince the powers that be to use Erlang. It seems
> to be working so far.
>
>         Thanks, Joel
>
> --
> http://wagerlabs.com/
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Andrés Valenciano
In reply to this post by Dmitrii Dimandt
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.

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



Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Roberto Saccon
For PDF you could use http://pdflib.de, wich is commercial, but worth
its price and ships with C source code, so you could build a
port-driver (never done that myself, I am also new to Erlang), and for
RPC with flash you could use Yarivs haxe remoting module.

On 8/28/06, Andrés Valenciano <[hidden email]> 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.
>
> 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
>
>
>
>


--
Roberto Saccon
Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

ke han
In reply to this post by Andrés Valenciano

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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Andrés Valenciano
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 :) )


> 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.

Thanks for the answers to my post.

-Andrés
Reply | Threaded
Open this post in threaded view
|

new blog entry

Joe Armstrong (TN/EAB)
Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Thomas Lindgren
In reply to this post by Andrés Valenciano


--- Andrés Valenciano <[hidden email]>
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 :) )

Most developers and managers play "follow the leader"
and get upset if there are several ones :-) But those
guys are basically the prize of the winner, and there
is little point in trying to convince them at this
stage.

Instead, I think what is needed is a community of
technical pioneers, who overcome real problems and
codify them into software solutions. This is
attractive to people who are having problems and are
willing to try something new. In this specific case,
an "OTP for web developers", perhaps?

Basically, these pioneers will be the core of the
snowball at the top of the hill, and the followers
will be the big outer layer at the bottom.

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

ke han
In reply to this post by Andrés Valenciano

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

Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

Dmitrii Dimandt
In reply to this post by Thomas Lindgren
Well, to add this to the mix:

Erlang is actually not suited very well for anything, but, well, telecom applications :)

Despite Yaws, it cannot be used as a web-development tool right out of the box (Unicode, indexed search anyone)
Despite C- and Java- bindings, Erlang cannot be used for desktop applications, because, well, you'll have to implement _a lot_ of stuff from ground up in Java or C/C++ just to make things communicate with Erlang

As a control box? Yes, definitely. As a ready-togo solution? Probably, not.

And there are both advantages and disadvantages to that, as there always are, but I think, that if Erlang community could focus on the disadvantages... Man, this could be the next killer-language :) (Ruby is slowly filling the void, and C# 3.0 is around the corner, and there is that curious little fellow by the name of Nemerle...)

On 8/29/06, Thomas Lindgren <[hidden email]> wrote:


--- Andrés Valenciano <[hidden email]>
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 :) )

Most developers and managers play "follow the leader"
and get upset if there are several ones :-) But those
guys are basically the prize of the winner, and there
is little point in trying to convince them at this
stage.

Instead, I think what is needed is a community of
technical pioneers, who overcome real problems and
codify them into software solutions. This is
attractive to people who are having problems and are
willing to try something new. In this specific case,
an "OTP for web developers", perhaps?

Basically, these pioneers will be the core of the
snowball at the top of the hill, and the followers
will be the big outer layer at the bottom.

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Reply | Threaded
Open this post in threaded view
|

Erlang does have problems

Joel Reymont

On Aug 29, 2006, at 4:59 PM, Dmitrii Dimandt wrote:

> And there are both advantages and disadvantages to that, as there  
> always
> are, but I think, that if Erlang community could focus on the
> disadvantages... Man, this could be the next killer-language :)  
> (Ruby is
> slowly filling the void, and C# 3.0 is around the corner, and there  
> is that
> curious little fellow by the name of Nemerle...)

Why not Ruby on the Erlang VM?

Even the "flagship" Erlang apps have their problems. ejabberd uses  
tons of memory because strings are being passed around as lists  
despite being received as binaries from the socket. This is a problem  
on 32-bit systems as it limits the number of users you can host and  
it's a bigger problem on 64-bit systems as words are LARGER.

The ejabberd developers came up with a fix, they are loading expat (C  
parser) as a driver. They are still using a port per message or per  
connection (don't remember exactly) and blow through the number of  
ports normally configured. Yes, you can up the number of ports but a  
better solution would be to stop using strings and create a shared  
pool of XML parser ports.

Some high-profile messaging startups are using ejabberd now, although  
they don't advertise it. They are also considering dropping ejabberd  
and either going with a commercial implementation or writing their  
own stuff. I know because I keep in touch with them.

Despite the Ericsson AXD 301 advocacy there are no high-profile  
Erlang deployments that I know about. There should be and we should  
all know! That is if we want Erlang to become mainstream. On the  
other hand, why bother?

--
http://wagerlabs.com/



Reply | Threaded
Open this post in threaded view
|

Re: Erlang for web-developers

yarivvv
In reply to this post by Dmitrii Dimandt
In a couple of months your opinion will be drastically different ;)

Yariv

On 8/29/06, Dmitrii Dimandt <[hidden email]> wrote:

> Well, to add this to the mix:
>
> Erlang is actually not suited very well for anything, but, well, telecom
> applications :)
>
> Despite Yaws, it cannot be used as a web-development tool right out of the
> box (Unicode, indexed search anyone)
> Despite C- and Java- bindings, Erlang cannot be used for desktop
> applications, because, well, you'll have to implement _a lot_ of stuff from
> ground up in Java or C/C++ just to make things communicate with Erlang
>
>  As a control box? Yes, definitely. As a ready-togo solution? Probably, not.
>
> And there are both advantages and disadvantages to that, as there always
> are, but I think, that if Erlang community could focus on the
> disadvantages... Man, this could be the next killer-language :) (Ruby is
> slowly filling the void, and C# 3.0 is around the corner, and there is that
> curious little fellow by the name of Nemerle...)
>
>
> On 8/29/06, Thomas Lindgren < [hidden email]> wrote:
> >
> >
> > --- Andrés Valenciano < [hidden email]>
> > 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 :) )
> >
> > Most developers and managers play "follow the leader"
> > and get upset if there are several ones :-) But those
> > guys are basically the prize of the winner, and there
> > is little point in trying to convince them at this
> > stage.
> >
> > Instead, I think what is needed is a community of
> > technical pioneers, who overcome real problems and
> > codify them into software solutions. This is
> > attractive to people who are having problems and are
> > willing to try something new. In this specific case,
> > an "OTP for web developers", perhaps?
> >
> > Basically, these pioneers will be the core of the
> > snowball at the top of the hill, and the followers
> > will be the big outer layer at the bottom.
> >
> > Best,
> > Thomas
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Erlang does have problems

lang er
In reply to this post by Joel Reymont
Would be these system reimplemented in Erlang or other languages if they have dropped ejabberd?

What's the status of <a href="http://jabber.org/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Jabber.org?

Is this string-binary problem  a language problem or ejabberd implementation issue?

BR!
james

2006/8/30, Joel Reymont <[hidden email]>:

On Aug 29, 2006, at 4:59 PM, Dmitrii Dimandt wrote:

> And there are both advantages and disadvantages to that, as there
> always
> are, but I think, that if Erlang community could focus on the
> disadvantages... Man, this could be the next killer-language :)
> (Ruby is
> slowly filling the void, and C# 3.0 is around the corner, and there
> is that
> curious little fellow by the name of Nemerle...)

Why not Ruby on the Erlang VM?

Even the "flagship" Erlang apps have their problems. ejabberd uses
tons of memory because strings are being passed around as lists
despite being received as binaries from the socket. This is a problem
on 32-bit systems as it limits the number of users you can host and
it's a bigger problem on 64-bit systems as words are LARGER.

The ejabberd developers came up with a fix, they are loading expat (C
parser) as a driver. They are still using a port per message or per
connection (don't remember exactly) and blow through the number of
ports normally configured. Yes, you can up the number of ports but a
better solution would be to stop using strings and create a shared
pool of XML parser ports.

Some high-profile messaging startups are using ejabberd now, although
they don't advertise it. They are also considering dropping ejabberd
and either going with a commercial implementation or writing their
own stuff. I know because I keep in touch with them.

Despite the Ericsson AXD 301 advocacy there are no high-profile
Erlang deployments that I know about. There should be and we should
all know! That is if we want Erlang to become mainstream. On the
other hand, why bother?

--
http://wagerlabs.com/




123