4 ms·

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 -

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...

vidarh 9y ago
I think this overcomplicates the problem. I have not written a high performance messaging system in PHP, but I have in both C and Ruby, and the quip about a "sufficient complicated concurrent program" was moot in both cases, because 1) there are plenty of approaches to doing this cleanly without writing a "complicated concurrent program" - here's one (I've done this in production; it worked great and all the work on federation has been done for you): use qmail or the qmail approach, of decomposing into small independent programs, and of which case crash and get restarted without causing any damage. Incidentally, yes, this depends on process isolation just like you'd expect with PHP, and yes, this is run of the mill stuff you can do with anything. That's the point - Whatsapp like message exchange is not rocket science, and how to structure this so you can just let processes die is something we solved literally decades ago. 2) even if you write a concurrent program to handle the queuing, the logic is simple enough that e.g. my first production queuing messaging system in Ruby was <700 lines of code, with ~10 lines protected by a Mutex making up the only place where the threads interacted with each other at all. I'm sure there are many spaces where Erlang could make a huge difference here. And as I said it's very much possible it'd have a performance impact, but this specific example isn't a complicated problem space. At all.
jeffdavis 9y ago
"there is virtually nothing in common between PHP and Erlang, other than them both being programming languages. The comparison is entirely fallacious" I just disagree. When I was reading an erlang book for the first time, that was one of the first things I thought: this sounds like the architecture of PHP working against a database. Hot code loading? I do that all the time -- just FTP the file, and the module will see that it changed and run the new version. Let it crash? Sure, PHP can do that too -- one runtime exception on unexpected input doesn't affect the other requests at all. By the way, I happen to like erlang and find PHP unpleasant to use and scary from a security standpoint. But I think a lot of people underestimate how good the PHP architecture was in a lot of ways.
- defined 9y ago
  Reading an Erlang book, no offense, is not going to give you the insight necessary to do a competent comparison of Erlang and PHP (or any other language). I am not sure if you have written any significant production systems using Erlang, and if you have, I apologize and withdraw the implication that insight is lacking. Please let me explain why this makes me raise an eyebrow. Let's take just one thing: hot code loading. When Erlang does hot code loading, it loads it into the currently running process. This means that any socket opened by that process stays open, and the connection is uninterrupted. The process doesn't stop running, or restart. In fact, the process is, for a short time, running both the old and the new code at the same time. When the process gets to the point of completing the recursive loop within which the old function was called, the new one gets switched in seamlessly and is called from there onwards. I know of no other language that has such mutable late binding, but I can't say they don't exist. This is, I believe, entirely different from an interpreter loading new code into a different process (or restarting the current one) on detecting a new file. If you can assert that after loading new code from a file, 1. The process pid is unchanged (it's literally the same process), and 2. The process data state is unchanged (it's literally the same process memory) and 3. The process file handles and sockets are unchanged maybe I could agree with your point of view.
  - vidarh 9y ago
    > When Erlang does hot code loading, it loads it into the currently running process. That is also usually true for PHP code using Fastcgi or mod_php or similar. It's not true for PHP code using PHP as a CGI, but nobody has done that since the 90's. It may depends on settings for opcode caching and the like. > This means that any socket opened by that process stays open, and the connection is uninterrupted. One of the earliest optimisations for PHP was the ability to make database connections persist across requests. See [1] for documentation of how to do this in current versions of PHP but it has been available pretty much from the start. > When the process gets to the point of completing the recursive loop within which the old function was called, the new one gets switched in seamlessly and is called from there onwards. I know of no other language that has such mutable late binding, but I can't say they don't exist. Plenty do. This is valid Ruby that replaces the method "foo" for each iteration of the currently running loop: (1..10).each do |i| eval(<<END) def foo puts #{i} end END foo end (the textual eval rather than simply inlining the method definition is necessary because "i" is a local variable not accessible from within the newly defined "foo" - if we used e.g. an instance variable instead it'd work, but then foo would effectively be static which would defeat the point of the demonstration) Ruby's and PHP's ability to do hot reloads is similar, but it needs the running script to cooperate in the loading unless you use a containing process that embeds the interpreter and does hot loading that way. But the PHP approach there is traditionally instead to throw away the code on each request. > 1. The process pid is unchanged (it's literally the same process), and 2. The process data state is unchanged (it's literally the same process memory) and 3. The process file handles and sockets are unchanged To me these are optimisations that are undesirable unless you need them. They're necessary for performance, but they make the system more vulnerable to working on corrupted data. As such I don't think it's a good distinction, but as mentioned depending on how you run PHP it can/will meet 1. and can meet 3. to some extent, and will meet 2. for session data, so it's up to you how much persists across requests. [1] http://php.net/manual/en/features.persistent-connections.php http://php.net/manual/en/features.persistent-connections.php

vidarh 9y ago

I think this overcomplicates the problem. I have not written a high performance messaging system in PHP, but I have in both C and Ruby, and the quip about a "sufficient complicated concurrent program" was moot in both cases, because 1) there are plenty of approaches to doing this cleanly without writing a "complicated concurrent program" - here's one (I've done this in production; it worked great and all the work on federation has been done for you): use qmail or the qmail approach, of decomposing into small independent programs, and of which case crash and get restarted without causing any damage. Incidentally, yes, this depends on process isolation just like you'd expect with PHP, and yes, this is run of the mill stuff you can do with anything. That's the point - Whatsapp like message exchange is not rocket science, and how to structure this so you can just let processes die is something we solved literally decades ago. 2) even if you write a concurrent program to handle the queuing, the logic is simple enough that e.g. my first production queuing messaging system in Ruby was <700 lines of code, with ~10 lines protected by a Mutex making up the only place where the threads interacted with each other at all. I'm sure there are many spaces where Erlang could make a huge difference here. And as I said it's very much possible it'd have a performance impact, but this specific example isn't a complicated problem space. At all.

jeffdavis 9y ago

"there is virtually nothing in common between PHP and Erlang, other than them both being programming languages. The comparison is entirely fallacious" I just disagree. When I was reading an erlang book for the first time, that was one of the first things I thought: this sounds like the architecture of PHP working against a database. Hot code loading? I do that all the time -- just FTP the file, and the module will see that it changed and run the new version. Let it crash? Sure, PHP can do that too -- one runtime exception on unexpected input doesn't affect the other requests at all. By the way, I happen to like erlang and find PHP unpleasant to use and scary from a security standpoint. But I think a lot of people underestimate how good the PHP architecture was in a lot of ways.

defined 9y ago
Reading an Erlang book, no offense, is not going to give you the insight necessary to do a competent comparison of Erlang and PHP (or any other language). I am not sure if you have written any significant production systems using Erlang, and if you have, I apologize and withdraw the implication that insight is lacking. Please let me explain why this makes me raise an eyebrow. Let's take just one thing: hot code loading. When Erlang does hot code loading, it loads it into the currently running process. This means that any socket opened by that process stays open, and the connection is uninterrupted. The process doesn't stop running, or restart. In fact, the process is, for a short time, running both the old and the new code at the same time. When the process gets to the point of completing the recursive loop within which the old function was called, the new one gets switched in seamlessly and is called from there onwards. I know of no other language that has such mutable late binding, but I can't say they don't exist. This is, I believe, entirely different from an interpreter loading new code into a different process (or restarting the current one) on detecting a new file. If you can assert that after loading new code from a file, 1. The process pid is unchanged (it's literally the same process), and 2. The process data state is unchanged (it's literally the same process memory) and 3. The process file handles and sockets are unchanged maybe I could agree with your point of view.
- vidarh 9y ago
  > When Erlang does hot code loading, it loads it into the currently running process. That is also usually true for PHP code using Fastcgi or mod_php or similar. It's not true for PHP code using PHP as a CGI, but nobody has done that since the 90's. It may depends on settings for opcode caching and the like. > This means that any socket opened by that process stays open, and the connection is uninterrupted. One of the earliest optimisations for PHP was the ability to make database connections persist across requests. See [1] for documentation of how to do this in current versions of PHP but it has been available pretty much from the start. > When the process gets to the point of completing the recursive loop within which the old function was called, the new one gets switched in seamlessly and is called from there onwards. I know of no other language that has such mutable late binding, but I can't say they don't exist. Plenty do. This is valid Ruby that replaces the method "foo" for each iteration of the currently running loop: (1..10).each do |i| eval(<<END) def foo puts #{i} end END foo end (the textual eval rather than simply inlining the method definition is necessary because "i" is a local variable not accessible from within the newly defined "foo" - if we used e.g. an instance variable instead it'd work, but then foo would effectively be static which would defeat the point of the demonstration) Ruby's and PHP's ability to do hot reloads is similar, but it needs the running script to cooperate in the loading unless you use a containing process that embeds the interpreter and does hot loading that way. But the PHP approach there is traditionally instead to throw away the code on each request. > 1. The process pid is unchanged (it's literally the same process), and 2. The process data state is unchanged (it's literally the same process memory) and 3. The process file handles and sockets are unchanged To me these are optimisations that are undesirable unless you need them. They're necessary for performance, but they make the system more vulnerable to working on corrupted data. As such I don't think it's a good distinction, but as mentioned depending on how you run PHP it can/will meet 1. and can meet 3. to some extent, and will meet 2. for session data, so it's up to you how much persists across requests. [1] http://php.net/manual/en/features.persistent-connections.php http://php.net/manual/en/features.persistent-connections.php