Discussion:
Erlang for web-developers
(too old to reply)
unknown
2006-08-28 07:50:02 UTC
Permalink
I couldn't leave a reply to Yariv's
post<http://yarivsblog.com/articles/2006/08/27/to-web-developers-think-outside-the-thread>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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060828/6ef6a861/attachment.html>
unknown
2006-08-28 09:15:23 UTC
Permalink
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" <dmitriid>
Date: Mon, August 28, 2006 10:50 am
To: "Erlang-Questions Mailing List" <erlang-questions>
I couldn't leave a reply to Yariv's post because of some error I kept on receiving, so I decided to respond here.
- Mnesia is a nice database for small amounts of data - 4-8 GB, not more :))) (am I correct on this estimate?)
-- 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?
unknown
2006-08-28 11:26:13 UTC
Permalink
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
unknown
2006-08-28 12:47:17 UTC
Permalink
Hi Dmitri,
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
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
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
unknown
2006-08-28 13:41:27 UTC
Permalink
Post by unknown
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/
unknown
2006-08-28 15:31:48 UTC
Permalink
Post by unknown
Post by unknown
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/
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060828/1ed8596b/attachment.html>
unknown
2006-08-28 18:15:51 UTC
Permalink
Post by unknown
Post by unknown
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
Post by unknown
--
http://wagerlabs.com/
unknown
2006-08-28 18:32:41 UTC
Permalink
Post by unknown
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/
unknown
2006-08-28 20:44:24 UTC
Permalink
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/
unknown
2006-09-03 10:33:10 UTC
Permalink
Post by unknown
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.
How do you handle sessions? If they are stored as files in /tmp they are
not removed by rails and you will reach the maximum number of files in a
directory after a while, and I guess these are removed on reboot. This
is a known problem and examples of cron jobs are available in the Rails
docs. Another approach is to store sessions in a database, but also
these need to be cleaned up not to fill the database.
Post by unknown
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 :)
<snip>
Post by unknown
Thanks,
Yariv
Regards
--
?Oscar Hellstr?m, oscar
web: personal.oscarh.net
jid: oscar
unknown
2006-08-29 02:55:39 UTC
Permalink
Post by unknown
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
unknown
2006-08-29 03:45:16 UTC
Permalink
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.
Post by unknown
Post by unknown
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
unknown
2006-08-29 04:05:51 UTC
Permalink
Post by unknown
Post by unknown
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
Post by unknown
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
unknown
2006-08-29 12:44:02 UTC
Permalink
Post by unknown
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 :) )
Post by unknown
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
unknown
2006-08-29 15:28:35 UTC
Permalink
Post by unknown
Post by unknown
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.
Post by unknown
Post by unknown
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
Post by unknown
Thanks for the answers to my post.
-Andr?s
unknown
2006-08-30 10:23:31 UTC
Permalink
Post by unknown
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?
Don't forget to emphasize that Erlang is not only free and open source, but
heavily tested and mature, perhaps moreso than Cold Fusion. Two *huge*
benefits over Cold Fusion or anything else proprietary. Do a little
research and find out how much the CF license costs.
--
View this message in context: http://www.nabble.com/Erlang-for-web-developers-tf2175872.html#a6056153
Sent from the Erlang Questions forum at Nabble.com.
unknown
2006-08-29 14:12:08 UTC
Permalink
http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html

/Joe
unknown
2006-08-29 14:13:54 UTC
Permalink
--- Andr?s Valenciano <andres-lists>
Post by unknown
Post by unknown
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
unknown
2006-08-29 15:59:45 UTC
Permalink
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...)
Post by unknown
--- Andr?s Valenciano <andres-lists>
Post by unknown
Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060829/66bbef53/attachment.html>
unknown
2006-08-29 17:02:36 UTC
Permalink
Post by unknown
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/
unknown
2006-08-29 18:34:31 UTC
Permalink
Would be these system reimplemented in Erlang or other languages if they
have dropped ejabberd?

What's the status of Jabber.org <http://jabber.org/>?

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

BR!
james
Post by unknown
Post by unknown
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060830/e55b0833/attachment.html>
unknown
2006-08-29 18:44:57 UTC
Permalink
Post by unknown
Would be these system reimplemented in Erlang or other languages if
they have dropped ejabberd?
Other languages.
Post by unknown
What's the status of Jabber.org?
What do you mean?
Post by unknown
Is this string-binary problem a language problem or ejabberd
implementation issue?
Both Erlang choosing to represent strings as lists of 4 or 8-byte
integers and ejabberd using strings to represent XML messages flowing
through the system.

Joel

--
http://wagerlabs.com/
unknown
2006-08-29 19:06:44 UTC
Permalink
Thanks.
Because I'm evaluating building our new server in Erlang.So I'm very
concerned about these problems.
Post by unknown
Post by unknown
Would be these system reimplemented in Erlang or other languages if
they have dropped ejabberd?
Other languages.
Are there any other problems,or mainly because string memory usage?
Post by unknown
What's the status of Jabber.org?
What do you mean?
Jabber.org, the public Jabber server of the Jabber Software
Foundation<http://www.jabber.org/>(JSF) migrated from jabberd
1.4 <http://jabberd.org/> CVS to ejabberd <http://ejabberd.jabber.ru/>
1.0.0on February 26, 2006

I think jabber.org has many registered users and very busy traffic , maybe
the status of jabber.org can provide more informations about these
problems.
Post by unknown
Is this string-binary problem a language problem or ejabberd
Post by unknown
implementation issue?
Both Erlang choosing to represent strings as lists of 4 or 8-byte
integers and ejabberd using strings to represent XML messages flowing
through the system.
Oh! So if a 64-bit machine is used.....

But I guess it is not very difficult to fix this issue in future release(if
the core team does think it is a problem), despite need add some
complexities to compiler / VM.

Best Regards!

james
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060830/49ebb2c4/attachment.html>
unknown
2006-08-29 19:14:31 UTC
Permalink
Post by unknown
But I guess it is not very difficult to fix this issue in future release(if
the core team does think it is a problem), despite need add some
complexities to compiler / VM.
Use binaries. ejabberd already does this in some places, just not
everywhere.

--
http://wagerlabs.com/
unknown
2006-08-29 19:52:26 UTC
Permalink
Post by unknown
Post by unknown
Would be these system reimplemented in Erlang or other languages if
they have dropped ejabberd?
Other languages.
Other languages have problems, too :) No language is perfect. The
strings issue seems rather small in the grand scheme of things.
There's a finite number of functions in the lists module, and they can
all be implemented on top of native buffers.

In the meantime, I'll add binaries support to ErlyDB :)

Yariv
unknown
2006-08-29 19:12:04 UTC
Permalink
Post by unknown
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.
If this is really THE problem for Erlang systems, I think Erlang
should be extended with a native String type. It would have similar
functions to lists, but be more efficient. It really doesn't sound
like such an insurmountable issue to me, but maybe I'm understimating
what it would take.
Post by unknown
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.
I know that Meebo, jabber.org, and Gizmo project all use Ejabberd and
as far as I know they are happy with it. These are all very big
deployments.
Post by unknown
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?
Erlang doesn't have to become mainstream. It just has to make OUR
lives easier. That's my take on it, anyway :)

Best,
Yariv
unknown
2006-08-29 19:16:02 UTC
Permalink
Post by unknown
If this is really THE problem for Erlang systems, I think Erlang
should be extended with a native String type. It would have similar
functions to lists, but be more efficient.
Just use binaries (tm).
Post by unknown
I know that Meebo, jabber.org, and Gizmo project all use Ejabberd and
as far as I know they are happy with it.
Ask again, I can't point fingers ;-).


--
http://wagerlabs.com/
unknown
2006-08-30 08:12:29 UTC
Permalink
Post by unknown
Post by unknown
If this is really THE problem for Erlang systems, I think Erlang
should be extended with a native String type. It would have similar
functions to lists, but be more efficient.
Just use binaries (tm).
This could be problematic for the developer who is not very well versed in
the fine arts of strings, binaries, conversions, encodings, etc etc etc :)
Especially for us, poor folks from non-English-speaking countries ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060830/e0b73927/attachment.html>
unknown
2006-08-30 09:06:45 UTC
Permalink
Post by unknown
This could be problematic for the developer who is not very well versed in
the fine arts of strings, binaries, conversions, encodings, etc etc etc :)
Especially for us, poor folks from non-English-speaking countries ;)
True. Non-English-speaking countries are not my target audience so I
did not even think about Unicode and encodings. My bad :-(.

--
http://wagerlabs.com/
unknown
2006-08-30 15:25:27 UTC
Permalink
Post by unknown
Post by unknown
Post by unknown
If this is really THE problem for Erlang systems, I think Erlang
should be extended with a native String type. It would have similar
functions to lists, but be more efficient.
Just use binaries (tm).
This could be problematic for the developer who is not very well versed in
the fine arts of strings, binaries, conversions, encodings, etc etc etc :)
Especially for us, poor folks from non-English-speaking countries ;)
How is it less of a problem with lists? There still isn't any support
for text encodings in what ships with Erlang (that I've been able to
find, anyway).

-bob
unknown
2006-08-30 16:36:16 UTC
Permalink
Post by unknown
How is it less of a problem with lists? There still isn't any support
for text encodings in what ships with Erlang (that I've been able to
find, anyway).
I (naively?) assumed that it's easier to process text encodings using
lists than binaries. It should be the same, now that I think about
it, just using much less space with binaries and maybe even faster.

--
http://wagerlabs.com/
unknown
2006-08-30 17:07:50 UTC
Permalink
Post by unknown
Post by unknown
How is it less of a problem with lists? There still isn't any support
for text encodings in what ships with Erlang (that I've been able to
find, anyway).
I (naively?) assumed that it's easier to process text encodings using
lists than binaries. It should be the same, now that I think about
it, just using much less space with binaries and maybe even faster.
You could reasonably work with (lists of?) UTF-8 binaries as the
in-memory representation. With that representation, you often won't
have to convert things again for the wire.

-bob
unknown
2006-08-30 20:00:43 UTC
Permalink
No, while binaries, or a string data type equivalent, are definitely
much more space efficient (a factor 2-8 depending on encoding) they are
probably much slower for processing strings. Especially for pulling them
apart and rebuilding them, and inserting or deleting bits which would
entail much copying. Of course you could make a more complex datatype
which keeps the characters in a linked sequence ... :-)

Strings as lists also has the benefit that you can more easily work on
16 or 32 bit unicode characters directly without worrying about
encoding. Then encode them when done. I would keep the statis strings as
binaries and dynamic ones as lists.

Robert
Post by unknown
Post by unknown
How is it less of a problem with lists? There still isn't any support
for text encodings in what ships with Erlang (that I've been able to
find, anyway).
I (naively?) assumed that it's easier to process text encodings using
lists than binaries. It should be the same, now that I think about it,
just using much less space with binaries and maybe even faster.
--
http://wagerlabs.com/
unknown
2006-08-30 20:29:12 UTC
Permalink
The overhead of lists-as-strings on 64-bit platforms is 8x for latin-1
text for just the 8-bit vs 64-bit data types, which completely ignores
the overhead of the list itself and whatever overhead there is to
tracking integers (if that's what Erlang does). At some point, all of
that storage bloat has to end up being a loss due to all of the memory
bandwidth being used up.

Inserting and deleting pieces could be fast operations if
iodata-of-just-binaries were allowed instead of requiring binaries.
All of the slicing and dicing should be memory-friendly since the
majority of the time it will be a view on some larger binary in
memory... so really it should be faster and more memory efficient in
many cases because splitting a binary in half doesn't require copying
of the first N/2 elements of the list.

-bob
Post by unknown
No, while binaries, or a string data type equivalent, are definitely
much more space efficient (a factor 2-8 depending on encoding) they are
probably much slower for processing strings. Especially for pulling them
apart and rebuilding them, and inserting or deleting bits which would
entail much copying. Of course you could make a more complex datatype
which keeps the characters in a linked sequence ... :-)
Strings as lists also has the benefit that you can more easily work on
16 or 32 bit unicode characters directly without worrying about
encoding. Then encode them when done. I would keep the statis strings as
binaries and dynamic ones as lists.
Robert
Post by unknown
Post by unknown
How is it less of a problem with lists? There still isn't any support
for text encodings in what ships with Erlang (that I've been able to
find, anyway).
I (naively?) assumed that it's easier to process text encodings using
lists than binaries. It should be the same, now that I think about it,
just using much less space with binaries and maybe even faster.
--
http://wagerlabs.com/
unknown
2006-08-30 20:44:19 UTC
Permalink
Bob,

Can you please elaborate on the iodata-of-binaries bit and on what
you see as wrong right now?
Post by unknown
Inserting and deleting pieces could be fast operations if
iodata-of-just-binaries were allowed instead of requiring binaries.
All of the slicing and dicing should be memory-friendly since the
majority of the time it will be a view on some larger binary in
memory...
--
http://wagerlabs.com/
unknown
2006-08-30 21:05:46 UTC
Permalink
Storing text as lists-of-integers is suboptimal for storage. It
doesn't particularly bother me, because I'm simply not working with
much text. The text I am working with in my current application is
relatively static, so I can treat most of it as lists of UTF8
binaries... but that also means I have to write most of my own
functions for operating on it. That's disappointing, but it doesn't
bother me much because the strings module doesn't really provide much
functionality either so I really am not missing much.

iodata-of-binaries just means that such a binary-strings module
could/should be able to handle lists-of-binaries in addition to raw
binaries.. just like nearly all of the IO functions can deal with
iodata. That way you could avoid unnecessary copying because you can
use [<<"foo">>, <<"bar">>] to concatenate instead of
iolist_to_binary([<<"foo">>, <<"bar">>]).

Splitting binaries should already be faster than splitting lists in
many cases, because the VM can choose to create views on the larger
binary. Concatenation of binaries requires copying, so that's why it
may be better to allow iodata instead of just pure strings, since
copying can be avoided.

I'm also not terribly convinced that lists are better for
concatenation, because adding data to the end of a list requires a lot
of copying and that's the most common operation in my experience. It
really depends on how many operations you're doing and how many
intermediate binaries you need to create. The binary copying might
take less memory and be faster than all of the copying incurred by
lists:reverse or whatever.

In any case, what's needed is a prototype and some benchmarks that can
be tested for performance on several kinds of machines to see what
works well under which circumstances. The current implementation is
good enough for me, so I'm not inclined to put in that kinda effort.

-bob
Post by unknown
Bob,
Can you please elaborate on the iodata-of-binaries bit and on what
you see as wrong right now?
Post by unknown
Inserting and deleting pieces could be fast operations if
iodata-of-just-binaries were allowed instead of requiring binaries.
All of the slicing and dicing should be memory-friendly since the
majority of the time it will be a view on some larger binary in
memory...
--
http://wagerlabs.com/
unknown
2006-08-30 17:47:29 UTC
Permalink
Look in the xmerl package. I think the file is called xml_ucs or something.

Yariv
Post by unknown
How is it less of a problem with lists? There still isn't any support
for text encodings in what ships with Erlang (that I've been able to
find, anyway).
-bob
unknown
2006-08-29 20:26:11 UTC
Permalink
Hello Guys,

You know what ?
I have heard that motorbikeis are difficult to drive. I even happen to
know a Nobel Prize that cannot manage to drive his brand new motorbike.
He his now seriously thinking about buy a Lincoln town car with driver.

And I was about to forgot: hammers are not perfect. I did not manage to
cut my chimney wood with them.

Now a little quizz, what have motorbikes, cars, hammers, saw, Erlang,
ejabberd, you name it, have in common ?
Yes, right they are "tools". Tools have in common:
- To fill a properly defined need,
- To need know-how to make them usefull.

Let's know discuss a thing that I know very well: ejabberd. I work for a
company that develops ejabberd, employs the main ejabberd developers and
have tens of customers running ejabberd.
Post by unknown
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.
Expat use is not at all related to a memory problem. It is related to
effiency. The XMPP protocol rely on a stream parser. Expat is probably
the most ancien, stable and efficient stream parser around. This is the
reason why it is used in ejabberd.
Post by unknown
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.
This sentence seems very definitive, but believe me, we probably are in
contact with all the big ejabberd users. We are helping them making
ejabberd working very well for them. We have tens of customers relying
on ejabberd for strategic services: this means that if ejabberd is down
they loose money. ejabberd has been deployed on sites with more than 135
000 simultaneously connected users. Some customers are switching from
commercial implementation to ejabberd. We are working on architectural
changes to support 500 000 simultaneous users.
Believe me, from experience, I know that using a commercial software
will not solve automagically the problem. ejabberd is a wonderfull tool.
At this level, commercial software are also tool and you have to put the
time and effort to make your solution work as well.

However, ejabberd and Erlang work very well when the user consider
them as a tool and not as a product. Running a service with this
amount of users if _HARD_. Read my lips. _Very hard_. You cannot take a
software out of the box deploy it and connects millions of users. Never.
This happens in big hardware vendors commercials, but not in real life.
You have to know the context of your deploiement. You have to know your
tool very well. You have to change it, improve it, optimize it. This is
what we are doing every days and our deployements are working extremely
well.
Reaching this level of knowledge and intimacy with your tool is a lot of
work, but Erlang is very rewarding in this aspect. If you take it as a
tool and are ready to doubt and question your approach and
implementation it can do wonders.

It happens sometimes however, that some of our contacts:
- absolutly wants to deal with a product, where obviously their business
model is based on differenciation. How could a product make them
different ?
- does not have the knowledge to operate the tool.
- does not have the budget to have someone to help them operate the
tool. This happens sometimes with startup. They put the money into
hiring people, but cannot then justify to need other external
know-how.
Post by unknown
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?
There are. I know many of them. I have not work of all of them but I
have also learn about them year after year in the Erlang community. But
as it is often explained in the Erlang community, companies having a
strategic advantage with Erlang does not necessarily want it to be
largely known and adopted. Erlang developers generally wants Erlang to
have the bare minimum of growth to progress, but do not care about it
being largely known or even largely used.
Erlang is a competive advantage and as such you should forget what I
have explained you previously in this mail.

Please, Joel, do me a favor. Do not thow away a tool each time someone
has trouble using it.

Cheers,
--
Micka?l R?mond
http://www.process-one.net/
unknown
2006-08-29 21:02:17 UTC
Permalink
Post by unknown
Expat use is not at all related to a memory problem. It is related to
effiency. The XMPP protocol rely on a stream parser. Expat is probably
the most ancien, stable and efficient stream parser around. This is the
reason why it is used in ejabberd.
I fully agree with you. I just got an idea to build on top of
ejabberd and yaws. I'm also hipe-d by my recent porting
experience :-). I might tackle a shared pool of expat drivers since I
believe this is what's needed. Memory use can be easily improved by
giving binaries to the expat driver since it takes them. This is not
being done last time I looked, not everywhere.
Post by unknown
Please, Joel, do me a favor. Do not thow away a tool each time someone
has trouble using it.
Oh, I don't give up on Erlang. It's great for network programming so
whenever I get to network programming I immediately think Erlang! It
saddens me when someone else gives up on it but I always try to help
and make sure people understand their options. Personally, I'm
embarking on a new venture involving yaws and likely ejabberd.

--
http://wagerlabs.com/
unknown
2006-08-29 21:36:18 UTC
Permalink
Post by unknown
Expat use is not at all related to a memory problem. It is related to
effiency. The XMPP protocol rely on a stream parser. Expat is probably
the most ancien, stable and efficient stream parser around. This is the
reason why it is used in ejabberd.
I fully agree with you. I just got an idea to build on top of ejabberd
and yaws. I'm also hipe-d by my recent porting experience :-). I might
tackle a shared pool of expat drivers since I believe this is what's
needed. Memory use can be easily improved by giving binaries to the
expat driver since it takes them. This is not being done last time I
looked, not everywhere.
erlsom is quite promising.

XML is thought as really generic solution for all possible problems with
generic parsers to handle it.

Principle of universal effectiveness:
More generic tool is - less efficient.
More specialized tool is - more efficient.

best regards,
taavi
unknown
2006-08-29 21:42:21 UTC
Permalink
Post by unknown
erlsom is quite promising.
XML is thought as really generic solution for all possible problems with
generic parsers to handle it.
Erlsom schema for RSS, anyone?

--
http://wagerlabs.com/
unknown
2006-08-29 17:16:55 UTC
Permalink
In a couple of months your opinion will be drastically different ;)

Yariv
Post by unknown
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...)
--- Andr?s Valenciano < andres-lists>
Post by unknown
Post by unknown
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
unknown
2006-08-30 06:24:49 UTC
Permalink
:)) I've already triple-wow'ed in your blog :)) I guess, more wow's are on
the way :))
Post by unknown
In a couple of months your opinion will be drastically different ;)
Yariv
Post by unknown
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
Post by unknown
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
Post by unknown
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.
Post by unknown
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
Post by unknown
curious little fellow by the name of Nemerle...)
--- Andr?s Valenciano < andres-lists>
Post by unknown
Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060830/d7439412/attachment.html>
unknown
2006-08-29 20:54:23 UTC
Permalink
Quote:

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?

(end of quote)


What are you talking about ?

I've been working with the Nortel SSL-accelerator (market no.1) and the Nortel SSL-VPN (market no.2) for many years. I'm now working with a 24-7 system
that handles lots of customers and mucho dinero, all around the clock.
All these systems are written in Erlang. And I know of other high-profile systems also written in Erlang. So what are you talking about, I mean really ?

If you want to know, then go and read up on the Erlang proceedings that exist from the EUC and ACm Sigplan workshops.

--Tobbe
_________________________________________________________
Post sent from http://www.trapexit.org
unknown
2006-08-29 21:33:57 UTC
Permalink
Post by unknown
If you want to know, then go and read up on the Erlang proceedings
that exist from the EUC and ACm Sigplan workshops.
I guess your definition of high-profile may vary. Can you name high-
profile Rails deployments? I'm sure people can, even if they don't
attend the Sigplan workshops. Anyway, I'm fine with keeping Erlang
to myself and let everyone else read the proceedings.

--
http://wagerlabs.com/
unknown
2006-08-30 08:34:48 UTC
Permalink
Post by unknown
Post by unknown
If you want to know, then go and read up on the Erlang proceedings
that exist from the EUC and ACm Sigplan workshops.
I guess your definition of high-profile may vary. Can you name
high-profile Rails deployments? I'm sure people can, even if they don't
attend the Sigplan workshops. Anyway, I'm fine with keeping Erlang to
myself and let everyone else read the proceedings.
Do there really exist any Rails deployments that plays in the
same ball park as the AXD 301 ?

That would surprise me!

--Tobbe
Post by unknown
--
http://wagerlabs.com/
unknown
2006-08-30 06:57:01 UTC
Permalink
Hi Michael,

You're right my Royal Enfield Bullet is an absolute bugger to start.

<< if you're good you can have a try when you come to the Erlang
conferense >>

It also half crippled Mike Williams (one of the Erlang fathers)
who thought he would demonstrate how to kick start a 550 cc single
cylinder
machine, he used to ride a matchless so he thought he knew what he was
doing ...

It took about a year to be able to start it.

Here's the correct technique:

1) fuel on
2) full choke
3) Depress valve lifter and kick slowly six times
(to fill the carburettor with gas)
5) Depress valve lifter
6) Move kick start to just beyond top dead centre
7) Release valve lifter
8) Depress kick start by about 15% until you feel
some resistance
9) Twist gas control by about 20%
10) Put one foot on kick start, other on ground
11) Hold *both* handle bars, while, maintaining 9)
12) Throw yourself into air
13) Land on kick start, with the "kick from hell"
making sure that you "follow through" ie the final resting
position of the kick start is when it bumps
into the foot rest

If you do all of the exactly right - then it will start on the fist
kick.

Now this technique took about a year to learn.

By comparison installing and starting PHP, Apache and Mysql is really
easy.

And yaws is much easier

/Joe
-----Original Message-----
From: owner-erlang-questions
[mailto:owner-erlang-questions] On Behalf Of Mickael Remond
Sent: den 29 augusti 2006 22:26
To: Joel Reymont
Cc: Dmitrii Dimandt; Thomas Lindgren; Erlang-Questions Mailing List
Subject: Motorbikes does have problems (was Erlang does have problems)
Hello Guys,
You know what ?
I have heard that motorbikeis are difficult to drive. I even
happen to know a Nobel Prize that cannot manage to drive his
brand new motorbike.
He his now seriously thinking about buy a Lincoln town car
with driver.
unknown
2006-08-30 15:32:33 UTC
Permalink
Starting technique quite reminds me of my old British Small Arms
Victor 441cc thumper. No longer have it, gave it to a friend
for his birthday some time ago. I witnessed similar starting
experiences with people who thought it should be easy to start
(won at least one bet, too!). Easy once you understand ...

Looking forward to your new book, Joe!

~Michael
Post by unknown
Hi Michael,
You're right my Royal Enfield Bullet is an absolute bugger to start.
<< if you're good you can have a try when you come to the Erlang
conferense >>
It also half crippled Mike Williams (one of the Erlang fathers)
who thought he would demonstrate how to kick start a 550 cc single
cylinder
machine, he used to ride a matchless so he thought he knew what he was
doing ...
It took about a year to be able to start it.
1) fuel on
2) full choke
3) Depress valve lifter and kick slowly six times
(to fill the carburettor with gas)
5) Depress valve lifter
6) Move kick start to just beyond top dead centre
7) Release valve lifter
8) Depress kick start by about 15% until you feel
some resistance
9) Twist gas control by about 20%
10) Put one foot on kick start, other on ground
11) Hold *both* handle bars, while, maintaining 9)
12) Throw yourself into air
13) Land on kick start, with the "kick from hell"
making sure that you "follow through" ie the final resting
position of the kick start is when it bumps
into the foot rest
If you do all of the exactly right - then it will start on the fist
kick.
Now this technique took about a year to learn.
By comparison installing and starting PHP, Apache and Mysql is really
easy.
And yaws is much easier
/Joe
-----Original Message-----
From: owner-erlang-questions
[mailto:owner-erlang-questions] On Behalf Of Mickael Remond
Sent: den 29 augusti 2006 22:26
To: Joel Reymont
Cc: Dmitrii Dimandt; Thomas Lindgren; Erlang-Questions Mailing List
Subject: Motorbikes does have problems (was Erlang does have problems)
Hello Guys,
You know what ?
I have heard that motorbikeis are difficult to drive. I even
happen to know a Nobel Prize that cannot manage to drive his
brand new motorbike.
He his now seriously thinking about buy a Lincoln town car
with driver.
unknown
2006-08-31 03:01:39 UTC
Permalink
bi> I'm also not terribly convinced that lists are better for
bi> concatenation, because adding data to the end of a list requires a
bi> lot of copying and that's the most common operation in my
bi> experience.

Oh? At last check, "X = [A, B]" executed in O(1) time regardless of
the sizes of A & B. As far as I/O lists are concerned,
[<<"fo">>, [[], $o], [[[<<"ba">>]], <<"r">>]] yields the same effect as
<<"foobar">>.

If whatever library you're working can only tolerate "flat" lists(*),
then you're limited to O(length(A)) concatenation (lists:append/2, A
++ B, etc).

Richard O'Keefe's contributions to the "Strings (was: Re: are Mnesia
tables immutable?)" thread on this mailing list(**) are quite
informative and, IMO, should be mandatory reading for "strings"
people.

-Scott

(*) 1> lists:flatten([<<"fo">>, [[], $o], [[[<<"ba">>]], <<"r">>]]).
[<<"fo">>, 111, <<"ba">>, <<"r">>]

(**) That thread took place (roughly) between 27 June and 06 July,
2006.
unknown
2006-08-31 03:44:36 UTC
Permalink
Post by unknown
bi> I'm also not terribly convinced that lists are better for
bi> concatenation, because adding data to the end of a list requires a
bi> lot of copying and that's the most common operation in my
bi> experience.
Oh? At last check, "X = [A, B]" executed in O(1) time regardless of
the sizes of A & B. As far as I/O lists are concerned,
[<<"fo">>, [[], $o], [[[<<"ba">>]], <<"r">>]] yields the same effect as
<<"foobar">>.
If whatever library you're working can only tolerate "flat" lists(*),
then you're limited to O(length(A)) concatenation (lists:append/2, A
++ B, etc).
I was referring to the stdlib string library (and the idea of
"string()" in general, as far as Erlang documentation goes), which
refers to exactly "flat" lists of integers. Sure, it's possible to
write a string library that can work with iolists, and that'd be
great, but Erlang doesn't ship with one as far as I can tell.

1> string:tokens("foo|bar|baz", "|").
["foo","bar","baz"]
2> string:tokens(["foo", ["|bar|", "baz"]], "|").
[["foo",["|bar|","baz"]]]

-bob
unknown
2006-08-31 06:37:40 UTC
Permalink
Post by unknown
Richard O'Keefe's contributions to the "Strings (was: Re: are Mnesia
tables immutable?)" thread on this mailing list(**) are quite
informative and, IMO, should be mandatory reading for "strings"
people.
This is the thread:
http://article.gmane.org/gmane.comp.lang.erlang.general/16021

It outlines nicely many the problems with strings and encodings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060831/4e654e0d/attachment.html>
Continue reading on narkive:
Loading...