4 ms·

To me, the more fascinating fact is that Erlang enabled their massive ability to scale. http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-fac

To me, the more fascinating fact is that Erlang enabled their massive ability to scale. http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...

rudiger 12y ago
Not just Erlang/BEAM optimization, but the team's background in high performance, C-based systems on FreeBSD enabled them to achieve massive scale.
Ixiaus 12y ago
What's more fascinating is that erlang underpins many more staples of the internet than most geeks even know. WhatsApp is just one 19B example.
- jambo 12y ago
  Yep. Especially when you consider that things like RabbitMQ, Riak, ejabberd, etc. are written in Erlang and take advantage of OTP.
- pjmlp 12y ago
  Not only the Internet. A few German game studios are using it on their backends.
  - marktangotango 12y ago
    Physics in Erlang? Game scripting engine implemented in Erlang? What types of games are we talking about here?
    - pjmlp 12y ago
      I wrote backend. Physics and game scripting belong on the client side, usually. http://de.slideshare.net/wooga/erlang-the-big-switch-in-social-games http://de.slideshare.net/wooga/erlang-the-big-switch-in-soci... http://sdtimes.com/enterprises-can-learn-from-game-development/ http://sdtimes.com/enterprises-can-learn-from-game-developme...
dschiptsov 12y ago
The "miracle" of Erlang/OTP is that it is well-researched and based on proper concepts, so there is absolutely no usual bullshitting here. The crucial mantra by Joe Armstrong is "to model a behavior in a "parallel" real world one have to choice a proper abstraction (which is about granularity, not classes or objects), then everything follows". So they have selected a connection as a fundamental abstractions and a lightweight process as a unit of granularity. Everything else follows, indeed. Processes share nothing, so there is no locks, semaphores, race-conditions. There is even no loops - only recursive procedures, which could be restarted if crashed, or even its code could be replaced without stopping the service (why, a new copy of the code would be called "in a next recursive call", because it is stateless/pure-functional). Each lightweight Erlang process serves its own connection, so it is perfectly natural and efficient to block/sleep on it (the OS kernel will do the job). It is not a "busy waiting", and there are no callbacks either. No "event buses", no nonsense. There is no threads, so no shared state or even shared stack. If a process crashes (why should it? - it communicates with outside world only via message-passing) it cannot corrupt or lock any shared data, etc. The whole class of problems which comes form a flawed concept of pthreads does not arise. There is no "reactive asynchronous event processing (written in Java or Scala)", there is no non-blocking I/O (btw, the only real non-blocking I/O could be done by an OS - aio_read/write and friends). There is no meaningless over-abstraction. That is why it works so well. Mo magic.
deleted 12y ago
[deleted]

rudiger 12y ago

Not just Erlang/BEAM optimization, but the team's background in high performance, C-based systems on FreeBSD enabled them to achieve massive scale.

Ixiaus 12y ago

What's more fascinating is that erlang underpins many more staples of the internet than most geeks even know. WhatsApp is just one 19B example.

jambo 12y ago
Yep. Especially when you consider that things like RabbitMQ, Riak, ejabberd, etc. are written in Erlang and take advantage of OTP.
pjmlp 12y ago
Not only the Internet. A few German game studios are using it on their backends.
- marktangotango 12y ago
  Physics in Erlang? Game scripting engine implemented in Erlang? What types of games are we talking about here?
  - pjmlp 12y ago
    I wrote backend. Physics and game scripting belong on the client side, usually. http://de.slideshare.net/wooga/erlang-the-big-switch-in-social-games http://de.slideshare.net/wooga/erlang-the-big-switch-in-soci... http://sdtimes.com/enterprises-can-learn-from-game-development/ http://sdtimes.com/enterprises-can-learn-from-game-developme...

dschiptsov 12y ago

The "miracle" of Erlang/OTP is that it is well-researched and based on proper concepts, so there is absolutely no usual bullshitting here. The crucial mantra by Joe Armstrong is "to model a behavior in a "parallel" real world one have to choice a proper abstraction (which is about granularity, not classes or objects), then everything follows". So they have selected a connection as a fundamental abstractions and a lightweight process as a unit of granularity. Everything else follows, indeed. Processes share nothing, so there is no locks, semaphores, race-conditions. There is even no loops - only recursive procedures, which could be restarted if crashed, or even its code could be replaced without stopping the service (why, a new copy of the code would be called "in a next recursive call", because it is stateless/pure-functional). Each lightweight Erlang process serves its own connection, so it is perfectly natural and efficient to block/sleep on it (the OS kernel will do the job). It is not a "busy waiting", and there are no callbacks either. No "event buses", no nonsense. There is no threads, so no shared state or even shared stack. If a process crashes (why should it? - it communicates with outside world only via message-passing) it cannot corrupt or lock any shared data, etc. The whole class of problems which comes form a flawed concept of pthreads does not arise. There is no "reactive asynchronous event processing (written in Java or Scala)", there is no non-blocking I/O (btw, the only real non-blocking I/O could be done by an OS - aio_read/write and friends). There is no meaningless over-abstraction. That is why it works so well. Mo magic.

deleted 12y ago

[deleted]