5 ms·

You wrote a well thought out response. I owe you a response in kind. People have a tendency to overrate their rational capacity to reason out a viable decision

by maratd 14y ago

You wrote a well thought out response. I owe you a response in kind. People have a tendency to overrate their rational capacity to reason out a viable decision. While you listed a few solid critiques, the situation is infinitely more complex. And by infinitely, I do mean exactly that. As in, beyond your capacity to reason it out. In the end, the only right decision is a decision which withstands the test of time. Both Apache and PHP have done that and continue to do so. Apache holds 65.5% of the market [1]. PHP holds 77.9% of the market [2]. Those solutions are working, right now, for all of those people. That's reality, not grand "rational, non-masochistic" theories. [1] http://w3techs.com/technologies/details/ws-apache/all/all http://w3techs.com/technologies/details/ws-apache/all/all [2] http://w3techs.com/technologies/details/pl-php/all/all http://w3techs.com/technologies/details/pl-php/all/all Now that we're finished with that, I'm going to enjoy myself. > a architectural decision which made it nearly fundamentally incapable of solving the C10K problem. C10K is not a problem and never was. The limiting factor in the overwhelming majority of deployments is the pipe. Apache can saturate the pipe just as well as NGINX. You will saturate the pipe long before you reach 10K connections. Which is why people continue to use Apache. Being technologically superior is pointless when there are no real-world benefits to that technological superiority. On top of that, Apache's thread model provides it with greater stability. If a worker thread crashes for whatever reason, another will simply spin up. If your NGINX process dies, you'll need to wait until your monitoring solution brings it back up. Which could be a long time. > PHP is among the worst languages most sane programmers have ever used. Worse than COBOL? Yes, yes, a fractal of bad design! Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design. > Python is designed with an emphasis on readability Was that humor? Python shoves its version of readability down your throat and laughs as you choke on it. Not all of us get off on syntactically significant white-space. In fact, most of us don't. Which explains why Python is so unpopular. But I get, I get it. It's cool.

deleted 14y ago
[deleted]
ceol 14y ago
The first half of your post is basically a long-winded appeal to popularity. Yes, most people on the web use PHP and Apache. Most people on the web also need nothing more than a WordPress installation and their online needs are met. Does that mean WordPress is the best tool out there? You should stop confusing popularity with quality, because the two rarely overlap. > C10K is not a problem and never was. Somebody better tell the developers of nginx, Lighttpd, Tornado, node.js, Cherokee, Apache Deft, IIS, and Jetty! All those hours wasted developing solutions to a problem that doesn't exist. > Which is why people continue to use Apache. For someone who just decried a situation "infinitely more complex" a few line breaks ago, you sure did generalize the reason millions of servers use a certain piece of software. It couldn't be because Apache has an easier installation on most of the common distros or that cPanel/WHM, the most-used virtual hosting control panel, only supports Apache as its web server. It also couldn't be because of mod_php. This all stems from your conflation of popularity with quality. PHP did not become popular because it was good. It became popular because it was easy to learn and run. > Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design. Most of his criticisms were completely valid, so I'm not sure where you're getting the author doesn't have much experience in PHP. Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"? > Which explains why Python is so unpopular. Now I know you're spouting nonsense: https://github.com/languages/ https://github.com/languages/
- wvenable 14y ago
  > Most of his criticisms were completely valid Not even close. The author trolled through a bunch of other misinformed articles, copied some them verbatim mistakes and all. He doesn't know PHP and didn't research anything. > Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"? http://news.ycombinator.com/item?id=4177516 http://news.ycombinator.com/item?id=4177516
  - ceol 14y ago
    In regard to his "objects compare higher..." point, I think he was referring to this: class MyClass {} class YourClass {} $myclass = new MyClass(); $yourclass = new YourClass(); var_dump($myclass > $yourclass); // false var_dump($myclass < $yourclass); // false? In regard to his "there's no pass-by-object identity..." point, there's no way to do this: class MyClass {} $myclass = MyClass; $anotherclass = $myclass(); I really don't have the energy to refute the rest, but most of them are relatively subjective. (I say relatively because most of them promote better programming, but their absence doesn't directly harm)
flatline3 14y ago
Reading through your responses, I'm curious about how much experience you actually have in our industry. Most of what you claim is easily falsifiable. The idea that C10K doesn't matter is definitively untrue. I've worked with numerous large systems (games, content) where Apache was the problem, and swapping it out was the solution to making maximal use of the hardware and the (gigE+) pipes. Even outside of saturation, there are large-scale systems that benefit from being able to park an open socket and provide asynchronous notifications over that socket (in web terms, think websockets). If you're paying for a thread or process for every socket, this becomes prohibitively expensive very quickly. It's also not an unusual use case outside of traditional web development, and now with websockets, this kind of architecture is likely to see considerably more use. This approach provides numerous advantages to legacy polling approaches, but does not work on traditional short-lived connection software architectures. In addition to the above, your discussion of robustness really has no bearing on Apache's architectural suitability in production use-cases. Auto-restart functionality exists for other architectures, and in addition to that, it's standard practice to deploy multiple servers with automatic failover behind a load balancer -- in addition to the server process itself, the OS can crash, disk drives can fail, power supplies can blow, etc. Additionally, you shouldn't have production processes crashing regularly, and shouldn't be making significantly performance-impacting architectural choices on the basis of Apache's ability to restart a child process. Software crashes in production are a worst-case failure, akin to a drive failing, and should never be so common as to justify Apache's performance costs/constraints.

by maratd 14y ago

deleted 14y ago

[deleted]

ceol 14y ago

The first half of your post is basically a long-winded appeal to popularity. Yes, most people on the web use PHP and Apache. Most people on the web also need nothing more than a WordPress installation and their online needs are met. Does that mean WordPress is the best tool out there? You should stop confusing popularity with quality, because the two rarely overlap. > C10K is not a problem and never was. Somebody better tell the developers of nginx, Lighttpd, Tornado, node.js, Cherokee, Apache Deft, IIS, and Jetty! All those hours wasted developing solutions to a problem that doesn't exist. > Which is why people continue to use Apache. For someone who just decried a situation "infinitely more complex" a few line breaks ago, you sure did generalize the reason millions of servers use a certain piece of software. It couldn't be because Apache has an easier installation on most of the common distros or that cPanel/WHM, the most-used virtual hosting control panel, only supports Apache as its web server. It also couldn't be because of mod_php. This all stems from your conflation of popularity with quality. PHP did not become popular because it was good. It became popular because it was easy to learn and run. > Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design. Most of his criticisms were completely valid, so I'm not sure where you're getting the author doesn't have much experience in PHP. Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"? > Which explains why Python is so unpopular. Now I know you're spouting nonsense: https://github.com/languages/ https://github.com/languages/

wvenable 14y ago
> Most of his criticisms were completely valid Not even close. The author trolled through a bunch of other misinformed articles, copied some them verbatim mistakes and all. He doesn't know PHP and didn't research anything. > Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"? http://news.ycombinator.com/item?id=4177516 http://news.ycombinator.com/item?id=4177516
- ceol 14y ago
  In regard to his "objects compare higher..." point, I think he was referring to this: class MyClass {} class YourClass {} $myclass = new MyClass(); $yourclass = new YourClass(); var_dump($myclass > $yourclass); // false var_dump($myclass < $yourclass); // false? In regard to his "there's no pass-by-object identity..." point, there's no way to do this: class MyClass {} $myclass = MyClass; $anotherclass = $myclass(); I really don't have the energy to refute the rest, but most of them are relatively subjective. (I say relatively because most of them promote better programming, but their absence doesn't directly harm)

flatline3 14y ago

Reading through your responses, I'm curious about how much experience you actually have in our industry. Most of what you claim is easily falsifiable. The idea that C10K doesn't matter is definitively untrue. I've worked with numerous large systems (games, content) where Apache was the problem, and swapping it out was the solution to making maximal use of the hardware and the (gigE+) pipes. Even outside of saturation, there are large-scale systems that benefit from being able to park an open socket and provide asynchronous notifications over that socket (in web terms, think websockets). If you're paying for a thread or process for every socket, this becomes prohibitively expensive very quickly. It's also not an unusual use case outside of traditional web development, and now with websockets, this kind of architecture is likely to see considerably more use. This approach provides numerous advantages to legacy polling approaches, but does not work on traditional short-lived connection software architectures. In addition to the above, your discussion of robustness really has no bearing on Apache's architectural suitability in production use-cases. Auto-restart functionality exists for other architectures, and in addition to that, it's standard practice to deploy multiple servers with automatic failover behind a load balancer -- in addition to the server process itself, the OS can crash, disk drives can fail, power supplies can blow, etc. Additionally, you shouldn't have production processes crashing regularly, and shouldn't be making significantly performance-impacting architectural choices on the basis of Apache's ability to restart a child process. Software crashes in production are a worst-case failure, akin to a drive failing, and should never be so common as to justify Apache's performance costs/constraints.