4 ms·

> I believe this is actually why erlang never really took off widely -- a PHP script hitting the database is a better version of the same concept: the PHP code

> I believe this is actually why erlang never really took off widely -- a PHP script hitting the database is a better version of the same concept: the PHP code can crash, and that will cause a lost connection and a ROLLBACK in the database, getting you back to a known-good state and the other requests just continue working (security and other PHP jokes aside). Comparing Erlang to PHP + transactional DB is regrettable. Firstly, Erlang's "let it crash" philosophy, together with its sophisticated supervisor/worker framework, aims for resilience in the face of failure due to bugs or bad data. A PHP script hitting a database may be a better design for a simple web application, but it is in no way superior to the Erlang/OTP ecosystem for Erlang's primary use case: soft real-time, highly concurrent, resilient and robust systems. It cannot reasonably be compared to a scripting language + DB, nor does it make any sense to. Secondly, Erlang is also able to work with transactional databases, from its built-in Mnesia DBMS to Postgres and more. A more appropriate comparison would be between Erlang + DB vs PHP + DB, and then I think you will agree that Erlang would generally fare better than PHP in that case. WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres. Finally, claiming that Erlang didn't take off because it lacked the transactional semantics of PHP + DB does not compute, because I never saw any claim that Erlang offers transactional DB semantics (unless it happens to be using a transactional DB).

user5994461 9y ago
>>> WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres. They could have done it in Java, C# or Go. PHP/Python/Perl/Ruby are terrible for fast network applications.
- defined 9y ago
  > They could have done it in Java, C# or Go. Maybe. But I think with much greater difficulty. None of Java, C#, or Go has the built-in distributed processing capability of Erlang. The last time I looked into it, WhatsApp's infrastructure consisted of 256 2-node clusters, each node of which was capable of supporting between one and two million concurrently open TCP sockets. The 2-node clusters were combined into (IIRC) 16 "islands", some of which were geographically remote, and each of which communicated with the other using a distribution protocol written by WhatsApp in Erlang.
skrebbel 9y ago
I think you're right, but I also think that you're missing the point of the GP's argument. Most people aren't building WhatsApp, they're building a CRUD app. And PHP has very Erlang-like "let it crash" semantics if you squint your eyes: one request causing havoc will not affect others at all, especially if you use a transaction to control DB side effects. Compare this to a NodeJS server that fully terminates when one request causes an uncaught exception and you'll see that PHP and Erlang have more in common, philosophically, than people like to admit. So the way I read the GP is that despite its many safety guarantees, Erlang never got popular because PHP offers the most important of these guarantees in a more accessible way. In fact, I know of no language that offers better crash resilience and isolation than PHP. I can run 100 shared hosting customers' shitty PHP code on a single Apache server and they'll have a seriously hard time making their bugs impact other customers. Try that with Erlang :-)
- sitepodmatt 9y ago
  Hmmm.. Interesting. On the last point I disagree unless you are launching php process per request then you'll have to set mod_php or php_fpm recycling ridiculous high to cope with 100 customers and their shitty PHP code (or the shitty PHP code from the top 10 one-click solutions installed) leaking memory everywhere. On the isolation side the industry answer to this is nasty prop solutions like CloudLinux and other custom solutions where each customer essentially has a request pool (e.g 5 php-fpm waiting around under the uid of the user) - counter to most shitty PHP web hosting providers goal of density, 'lets keep this server lightly loaded for the highend packages - just put 5,000 account on it okay'. Typical PHP hosting is not pretty, they're about 10 years behind the times, cough cpanel.
  - skrebbel 9y ago
    Hah ok, I stand corrected :-) I still wager it'd be even harder to host code from multiple customers on a single erlang VM though!
- jeffdavis 9y ago
  "And PHP has very Erlang-like "let it crash" semantics if you squint your eyes: one request causing havoc will not affect others at all, especially if you use a transaction to control DB side effects." Exactly my point, thank you for clarifying. PHP crashes (in some form or another) all the time, but the application can still remain up because that PHP process only has state for the one request (kind of like a single erlang process having state for only one request).
vidarh 9y ago
> WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres. They could have built it in anything. Federating and sharding message delivery has been a solved problem for decades. Their tech stack choice certainly has server cost implications, so that does not mean I'm saying they should have just arbitrarily picked something. But in terms of engineering a solution there's simply nothing particularly hard about their messaging volumes - people do volumes like that all the time. Just not that many that do it between people. That's not to say the Whatsapp team is not impressive - to have set up and run a system like theirs with that few people is impressive, and it's very much possible Erlang + Mnesia was instrumental to that.
- defined 9y ago
  I'm sure they could have built it in assembly language, it is true. But they would still be developing it today and not be close to done. All these arguments - not just yours - are strawman arguments, because they avoid addressing my actual objection: there is virtually nothing in common between PHP and Erlang, other than them both being programming languages. The comparison is entirely fallacious. The fact that PHP can survive crashes without affecting other sessions is either due to the process isolation that you get for free in modern operating systems, or using external technology like HHVM, which is nothing like the Erlang BEAM engine. To quote Robert Virding: > Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang. Lest anyone think this to be arrogance, I'll quote Brian Acton: > Erlang is a generally good and useful general purpose language. There was serious thought and consideration that went into its construction. As one example, we’ve seen great benefits in high concurrency situations. We’ve also seen the ability to maintain great uptime as part of its hot code loading capabilities. Doubtless many high-volume messaging systems have been built. From my experience, it is also likely that the effort and defect density involved to do so was likely 4-5 times greater than it would have been to implement it in Erlang. This has been borne out by experiment[1] and the experience of many developers who have adopted Erlang after using other technologies. This is not to claim that Erlang is better than everything else, or a panacea. Like anything created in an imperfect world, it has imperfections. But for someone who has written servers that require high reliability, robustness, concurrency, uptime, and maintainability, one could not do much better than Erlang. Sadly, HN comment section is not the place to debate the finer details of competing language ecosystems, and much of this is in the realm of personal experience and opinion, so let me gracefully withdraw and thank you for your perspective. [1]: https://www.researchgate.net/publication/221211369_Comparing_C_and_ERLANG_for_motorola_telecoms_software https://www.researchgate.net/publication/221211369_Comparing...
stephenr 9y ago
> WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres. WhatsApp backend is a heavily customised ejabberd - an XMPP server written in Erlang. Sure, they could have picked one of the other XMPP servers in a different language (I know of at least servers in Java, Lua, C). So, I would say (as a developer who uses PHP in some situations) that while PHP is completely the wrong choice for an XMPP server, that isn't the main reason why WhatsApp used Erlang - they used it because they used an existing open source project as their base.
- pritambaral 9y ago
  I doubt WhatsApp chose XMPP first and then ejabberd/Erlang. Even if they had built a custom protocol, the massive-scale concurrency required would have made Erlang just as good a target to build on. Java could have come close, but Erlang was the language with first class Actor-model and native massive-scale concurrency support. Actually, they do use a custom protocol, one that heavily derives from XMPP. Turns out, they didn't need to build a backend from scratch in their chosen language because a similar one already existed. Without inputs from the WhatsApp engineers on their early choices, my version of things^ is at least just as valid as yours. EDIT: I was wrong. Source: an interview one of the creators of WhatsApp gave to wired: https://www.wired.com/2015/10/whatsapps-co-founder-on-how-the-iconoclastic-app-got-huge/ https://www.wired.com/2015/10/whatsapps-co-founder-on-how-th...
  - stephenr 9y ago
    > I doubt WhatsApp chose XMPP first You think it's just a coincidence that WhatsApp, FB messenger, Google Talk, EA Origin, PlayStation, HipChat, Cisco WebEx all use(d) XMPP for their IM/chat/VoIP? Just because it's open only to a single vendor's client and isn't federated, doesn't mean it isn't still basically XMPP.

user5994461 9y ago

>>> WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres. They could have done it in Java, C# or Go. PHP/Python/Perl/Ruby are terrible for fast network applications.

defined 9y ago
> They could have done it in Java, C# or Go. Maybe. But I think with much greater difficulty. None of Java, C#, or Go has the built-in distributed processing capability of Erlang. The last time I looked into it, WhatsApp's infrastructure consisted of 256 2-node clusters, each node of which was capable of supporting between one and two million concurrently open TCP sockets. The 2-node clusters were combined into (IIRC) 16 "islands", some of which were geographically remote, and each of which communicated with the other using a distribution protocol written by WhatsApp in Erlang.

skrebbel 9y ago

I think you're right, but I also think that you're missing the point of the GP's argument. Most people aren't building WhatsApp, they're building a CRUD app. And PHP has very Erlang-like "let it crash" semantics if you squint your eyes: one request causing havoc will not affect others at all, especially if you use a transaction to control DB side effects. Compare this to a NodeJS server that fully terminates when one request causes an uncaught exception and you'll see that PHP and Erlang have more in common, philosophically, than people like to admit. So the way I read the GP is that despite its many safety guarantees, Erlang never got popular because PHP offers the most important of these guarantees in a more accessible way. In fact, I know of no language that offers better crash resilience and isolation than PHP. I can run 100 shared hosting customers' shitty PHP code on a single Apache server and they'll have a seriously hard time making their bugs impact other customers. Try that with Erlang :-)

sitepodmatt 9y ago
Hmmm.. Interesting. On the last point I disagree unless you are launching php process per request then you'll have to set mod_php or php_fpm recycling ridiculous high to cope with 100 customers and their shitty PHP code (or the shitty PHP code from the top 10 one-click solutions installed) leaking memory everywhere. On the isolation side the industry answer to this is nasty prop solutions like CloudLinux and other custom solutions where each customer essentially has a request pool (e.g 5 php-fpm waiting around under the uid of the user) - counter to most shitty PHP web hosting providers goal of density, 'lets keep this server lightly loaded for the highend packages - just put 5,000 account on it okay'. Typical PHP hosting is not pretty, they're about 10 years behind the times, cough cpanel.
- skrebbel 9y ago
  Hah ok, I stand corrected :-) I still wager it'd be even harder to host code from multiple customers on a single erlang VM though!
jeffdavis 9y ago
"And PHP has very Erlang-like "let it crash" semantics if you squint your eyes: one request causing havoc will not affect others at all, especially if you use a transaction to control DB side effects." Exactly my point, thank you for clarifying. PHP crashes (in some form or another) all the time, but the application can still remain up because that PHP process only has state for the one request (kind of like a single erlang process having state for only one request).

vidarh 9y ago

> WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres. They could have built it in anything. Federating and sharding message delivery has been a solved problem for decades. Their tech stack choice certainly has server cost implications, so that does not mean I'm saying they should have just arbitrarily picked something. But in terms of engineering a solution there's simply nothing particularly hard about their messaging volumes - people do volumes like that all the time. Just not that many that do it between people. That's not to say the Whatsapp team is not impressive - to have set up and run a system like theirs with that few people is impressive, and it's very much possible Erlang + Mnesia was instrumental to that.

defined 9y ago
I'm sure they could have built it in assembly language, it is true. But they would still be developing it today and not be close to done. All these arguments - not just yours - are strawman arguments, because they avoid addressing my actual objection: there is virtually nothing in common between PHP and Erlang, other than them both being programming languages. The comparison is entirely fallacious. The fact that PHP can survive crashes without affecting other sessions is either due to the process isolation that you get for free in modern operating systems, or using external technology like HHVM, which is nothing like the Erlang BEAM engine. To quote Robert Virding: > Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang. Lest anyone think this to be arrogance, I'll quote Brian Acton: > Erlang is a generally good and useful general purpose language. There was serious thought and consideration that went into its construction. As one example, we’ve seen great benefits in high concurrency situations. We’ve also seen the ability to maintain great uptime as part of its hot code loading capabilities. Doubtless many high-volume messaging systems have been built. From my experience, it is also likely that the effort and defect density involved to do so was likely 4-5 times greater than it would have been to implement it in Erlang. This has been borne out by experiment[1] and the experience of many developers who have adopted Erlang after using other technologies. This is not to claim that Erlang is better than everything else, or a panacea. Like anything created in an imperfect world, it has imperfections. But for someone who has written servers that require high reliability, robustness, concurrency, uptime, and maintainability, one could not do much better than Erlang. Sadly, HN comment section is not the place to debate the finer details of competing language ecosystems, and much of this is in the realm of personal experience and opinion, so let me gracefully withdraw and thank you for your perspective. [1]: https://www.researchgate.net/publication/221211369_Comparing_C_and_ERLANG_for_motorola_telecoms_software https://www.researchgate.net/publication/221211369_Comparing...

stephenr 9y ago

> WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres. WhatsApp backend is a heavily customised ejabberd - an XMPP server written in Erlang. Sure, they could have picked one of the other XMPP servers in a different language (I know of at least servers in Java, Lua, C). So, I would say (as a developer who uses PHP in some situations) that while PHP is completely the wrong choice for an XMPP server, that isn't the main reason why WhatsApp used Erlang - they used it because they used an existing open source project as their base.

pritambaral 9y ago
I doubt WhatsApp chose XMPP first and then ejabberd/Erlang. Even if they had built a custom protocol, the massive-scale concurrency required would have made Erlang just as good a target to build on. Java could have come close, but Erlang was the language with first class Actor-model and native massive-scale concurrency support. Actually, they do use a custom protocol, one that heavily derives from XMPP. Turns out, they didn't need to build a backend from scratch in their chosen language because a similar one already existed. Without inputs from the WhatsApp engineers on their early choices, my version of things^ is at least just as valid as yours. EDIT: I was wrong. Source: an interview one of the creators of WhatsApp gave to wired: https://www.wired.com/2015/10/whatsapps-co-founder-on-how-the-iconoclastic-app-got-huge/ https://www.wired.com/2015/10/whatsapps-co-founder-on-how-th...
- stephenr 9y ago
  > I doubt WhatsApp chose XMPP first You think it's just a coincidence that WhatsApp, FB messenger, Google Talk, EA Origin, PlayStation, HipChat, Cisco WebEx all use(d) XMPP for their IM/chat/VoIP? Just because it's open only to a single vendor's client and isn't federated, doesn't mean it isn't still basically XMPP.