The nature of contemporary web applications seems to be getting closer and closer to Erlang's original problem domain: lots of clients, continuously pulling down small updates, with a need for consistent and low latency. Maybe it's finally Erlang's turn to shine?
For those who are perfectly comfortable with viewing PDFs directly, here's a link:
www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf
Interesting to see that they mention loving the hot code reloading/upgrades, but also that they don't use the OTP release/upgrade functionality.
I wonder what their process is.. Just coping over new .beams and loading them is fine for functional changes only, but you need a system to run code-upgrade hooks if you want to change the state being passed around.
As far as I know, you don't need releases and upgrade functionality to make use of the code-upgrade hooks. It simply works without them.
Releases and upgrades do make it simpler to synchronize what needs to be taken down in what order, restarted, left alone, etc. But simple updates are still doable without that.
I guess it's Gb (Gigabit).
Since the only traffic Facebook Chat has is presence, which is handled using separate C++ servers.
Out of 500M users (350M active users) not many of them use chat, maybe because by design it feels disconnected from the rest of the site.
I wonder if FB would be willing to post some of their load numbers...
Like... how many sessions are created per day, persisted from day to day, how many messages sent per chat session, how long windows stay open, how many restores, etc.
You don't have to hire engineers with N years of experience in Erlang, rather hire great engineers who are programming language polyglots, and even if they don't already know Erlang they'll get up to speed on it fast, as well as any other new and useful language that comes along.
It makes sense if building a service in that language means that you need to hire far fewer engineers to maintain because it is much better suited to handle the particular demands of that application, as erlang seems to be in this case
Node.js is nice for evented I/O, but does it solve any of the other problems Erlang is good at, such as distributed parallel processing? How do you scale a Node.js-based service horizontally over many servers?
You could write facebook chat in pretty much any half decent language. The question is how competent the developers are rather than what tool they decide to use.
It's not rocket science, it's mainly plumbing - moving data around.
[+] [-] cageface|15 years ago|reply
[+] [-] timdorr|15 years ago|reply
Erlang's definitely got a speed and concurrency advantage. More people should take the time to learn about it, as it fits a lot of use cases.
[+] [-] admp|15 years ago|reply
[+] [-] mikedmiked|15 years ago|reply
[+] [-] metabrew|15 years ago|reply
I wonder what their process is.. Just coping over new .beams and loading them is fine for functional changes only, but you need a system to run code-upgrade hooks if you want to change the state being passed around.
[+] [-] mononcqc|15 years ago|reply
Releases and upgrades do make it simpler to synchronize what needs to be taken down in what order, restarted, left alone, etc. But simple updates are still doable without that.
[+] [-] metabrew|15 years ago|reply
[+] [-] JonnieCache|15 years ago|reply
Would this be a gigabit or gigabyte? Usually I would just assume gigabit but in the case of facebook i dont feel so hasty...
[+] [-] nivertech|15 years ago|reply
[+] [-] DrJosiah|15 years ago|reply
Like... how many sessions are created per day, persisted from day to day, how many messages sent per chat session, how long windows stay open, how many restores, etc.
[+] [-] koski|15 years ago|reply
[+] [-] Aloisius|15 years ago|reply
[+] [-] SkyMarshal|15 years ago|reply
[+] [-] tgriesser|15 years ago|reply
[+] [-] iregdtoreply|15 years ago|reply
[+] [-] JonnieCache|15 years ago|reply
Info on how to connect to it here: http://www.facebook.com/sitetour/chat.php
[+] [-] revoltingx|15 years ago|reply
[deleted]
[+] [-] mcs|15 years ago|reply
[+] [-] kennu|15 years ago|reply
[+] [-] puzza007|15 years ago|reply
http://erlang.2086793.n4.nabble.com/node-js-compared-to-erla...
[+] [-] axod|15 years ago|reply
It's not rocket science, it's mainly plumbing - moving data around.