[lostcolony]

"Erlang rocks! Erlang continues to prove its capability as a versatile, reliable, high-performance platform. Though personally all the tuning and patching that was required casts some doubt on this claim."

Really? Because I would trust their claims all the more; they've been in the trenches, they had expertise in other languages (from the article, "Having built a high performance messaging bus in C++ while at Yahoo, Rick Reed is not new to the world of high scalability architectures."), and then they became -intimate- with the language, in removing bottlenecks to their specific use case...and they still make the claim Erlang is great in this domain. Whose opinion are you going to credit more than theirs?

(Also, I bet many of the patches they made that weren't specific to their use cases were submitted as patches to the BEAM)

[erichocean]

What it means is that unless you are comfortable modifying Erlang itself (BEAM, internal data structures, hash table allocations, etc.), then your install of Erlang won't scale like WhatsApp. You'll also need a ton of monitoring because Erlang definitely isn't of the "just turn it on, it'll be fine" variety. Nothing at that scale is.

That's fine, but people do tend to oversell Erlang IMO. The types of things Rick Reed talks about in his talk are standard issue stuff. Lock contention? Okay, how about using an architecture that doesn't require locks in the first place?

With Erlang, you're forced into the Erlang way from day one, and it'll be tough to escape. The good news is that Erlang has a good design overall, so as long as you can modify the engine under the hood, you'll be fine.

I don't think anyone should be scared away from Erlang, just be aware what you're getting into—like any other tech you could deploy.

[Xorlev]

Hard to avoid lock contention when it's happening in the OS.

[erichocean]

Yup, that's why you skip that too:

https://news.ycombinator.com/item?id=7180672

[rdtsc]

Yap some patches or suggestions made it in and the greater community benefited. Some lock contention points removed, memory management stuff etc.

Also remember this is just one visible project. Erlang VM is being developed actively and many other companies and people are contributing. For an almost 30 year old language it very active. Maps are coming in R17 so are dirty schedulers, {active,N} on sockets, lots of goodies.

[lostcolony]

I know; R17-rc1 was tagged a month ago.

This was more my being agog at the author viewing the work that was done to the BEAM as evidence -against- Erlang being great, rather than the fact that these people with that level of experience stayed with it, and still raved about it, as evidence in Erlang's favor. And that the issues they encountered are probably fixed any way, or apply only to their use case (and so may still exist, but have a tradeoff that is worth keeping in other use cases).

[wcummings]

Omg dirty schedulers are included too? I need a new pair of pants :x

Dealing with NIF threads just feels dirty

[signa11]

if someone is looking for more info on dirty-scheduler, here is slightly oldish slide: http://www.erlang-factory.com/upload/presentations/377/Ricka...