
Nuts & Bolts: Campfire loves Erlang - tortilla
http://www.37signals.com/svn/posts/1728-nuts-bolts-campfire-loves-erlang
======
davidw
No performance comparison with their _working_ C code. Hrmph. Erlang's a
better choice for this kind of thing because you don't have to worry about a
lot of the things that could go wrong in the C version, and it's a bit higher
level than C, but still... C is fast and working code is working code.

~~~
jlouis
I would presume the Erlang version is much smaller than the C version. Nobody
argues that Erlang is _faster_ than C, but it might be _fast enough_ for the
task at hand.

Functional programs tend to be slower than imperative programs. They also tend
to be much smaller. And they tend to be easier to understand and work with
once the programmer gets the right mindset.

This just shows another area where C is not the only competitor anymore.

~~~
erlanger
When dealing with high concurrency, Erlang will beat C.

~~~
davidw
What is Erlang written in, again?

Erlang makes it (a lot) _easier_ to write high concurrency code, if that's how
you define 'beat', but it's not "faster".

~~~
erlanger
Yes, you could theoretically struggle to write C code to work like Erlang, but
processes are very cheap in Erlang, and distributed, parallel code is
extremely easy to write. C performs well, but can be unstable; Yaws performs
as well as Nginx.

Erlang's greatest advantage is not in its vertical but its horizontal
scalability, which does have consequences for performance.

~~~
neilc
_you could theoretically struggle to write C code to work like Erlang_

Lots of people write non-blocking network servers in C (epoll, kqueue, etc --
libevent); that does not constitute "struggling to write C code that works
like Erlang", but it still delivers a very high-performance end result.

 _C performs well, but can be unstable_

C is perfectly "stable", it can just be hard to get right.

~~~
davidw
Where Erlang is really strong is that you can handle fairly long running
processes that won't block other stuff that's happening. Of course you can
find ways to do that in C, but it's just easier and way cleaner in Erlang.
This works because of Erlang's internal scheduler.

------
axod
Side point: Why are they still using polling in this day+age :/

~~~
ovi256
If I understand well, the client browser polls the server, via JS timers.
There is no practical, scalable way for the server to update the client
browser, so the client has to poll this way. Their code just answers these
polls.

Of course, performance wise, this sucks badly, because most of the time
polling returns no results.

~~~
simonw
There are a number of practical, scalable (albeit tricky to set up) ways of
pushing events from the server to the browser, gathered under the umbrella
term Comet. Google have been using Comet for chat within Gmail since around
2005.

~~~
a-priori
Facebook also uses it, with an Erlang backend, for Facebook Chat.

------
dugmartin
I'm surprised to read that the Campfire servers does a mysql connect on each
poll. I built an internal tool for my company similar to Campfire but allowed
tabbed conversations in the same window (so that you can have a visible thread
running with a few people without bothering others).

To store messages I used a simple PHP script that wrote out a json object per
line to a file named with room+date. To poll for messages when you opened the
client it would query the poller script with the room name and it would return
all the json objects for the current day as an array plus the length of the
file. On each subsequent poll the client would send the room name + the file
offset - the server script would then open the file, jump to the offset and
read in the rest of the file and return it as an array (empty if no new
content) plus the new length of the file. It scaled really well (not that we
had Campfire sized loads).

