Apache is a webserver from 1995. It uses a process (sometimes a thread) per request, a architectural decision which made it nearly fundamentally incapable of solving the C10K problem. Only back in January was the Event MPM added (and it's still experimental), allowing you to have many Keep-Alive connections open at once without degrading performance. Nginx was started in 2004, and is event-based allowing for much higher concurrency. (Yes, I'm hand waving.)
PHP is among the worst languages most sane programmers have ever used. The referenced article, "A Fractal of Bad Design" is a pretty good starting point if you want more details on why it sucks. PHP stands for letting amateurs code effectively. Python is designed with an emphasis on readability, and manages to have a rational type system and a fairly regular standard library.
Apache vs Nginx is about learning from the mistakes of your ancestors. Apache was designed with the 90s in mind, and our technology has moved on to the point where the decisions made in its architecture simply don't work anymore.
PHP vs Python is about being a rational, non-masochistic, human being.
To say what is cool "has nothing to do with any objective qualities of the [technologies involved]" is to know nothing about programming as a business.
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 [2] 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.
> 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/
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"?
class MyClass {}
class YourClass {}
$myclass = new MyClass();
$yourclass = new YourClass();
var_dump($myclass > $yourclass); // false
var_dump($myclass < $yourclass); // false?
class MyClass {}
$myclass = MyClass;
$anotherclass = $myclass();
That all comparisons between objects, except equals and strict equals, return false doesn't seem terribly unreasonable.
> In regard to his "there's no pass-by-object identity..." point, there's no way to do this:
class MyClass {}
$myclass = new ReflectionClass('MyClass');
$anotherclass = $myclass;
$instance = $anotherclass->newInstance();
$myclass = 'MyClass';
$instance = new $myclass();
I think you'll be hard pressed to find too much fault with my criticisms of that article. The author doesn't even know common language terms like private/public/protected. And clearly he's never even seen C++.
It should throw an error, not return false. This goes back to PHP's "try as hard as possible to run the script" mentality.
The author doesn't need to know C++ to comment on PHP's failings, does he? And he knows private/public/protected— you even quote him using them. You're probably not familiar with Python, but there aren't any private methods (aside from double underscored-prefixed methods, but that's not entirely the same). That's where he was coming from. It's not that he doesn't know those terms; it's that he thinks that's how they should work.
Judging by your other responses, you're quick to toss out whether someone is a "PHP programmer" or not, as if that has any bearing on their argument. I'll tell you right now, I work in PHP five days a week, and I agree with most all of eevee's points.
I don't disagree. Although I think this goes towards PHP weak typing not it's try as hard to run the script.
> It's not that he doesn't know those terms; it's that he thinks that's how they should work.
He thinks they shouldn't exist at all. Which is one philosophy but that's not a valid criticism.
> I'll tell you right now, I work in PHP five days a week, and I agree with most all of eevee's points.
Even where he clearly doesn't know what he's talking about and didn't try the code he was supposedly saying doesn't work?
Those who don't know their tools are bound to have more problems or believe things that are just wrong.
No it's not. We're not talking about music --how popular Bieber is vs Bach, for example. So he didnt just say "tons of people use PHP", he said "tons of people use PHP and it solves their problems giving results".
This is not an "argument by popularity", its an argument by number of empirical verifications. Which is supposedly what engineering and science is all about.
On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results. "That's (eg python) is how a language should be, and not like php" etc. All the while forgetting to take no account practical, verified, php benefits.
>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?
OIf it meets their needs and has them happy, of course! Anything else would be dellusional to say.
The original discussion was about whether PHP was a good language. He came in and said, "It is because look at all the people who use it! Obviously it's fine!" That's an appeal to popularity.
> On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results.
What results? We're not talking about Mom & Pop's Homepage, here. Posting about how most sites run on PHP doesn't help us when we're not talking about most sites. We're talking about building apps.
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.
I hear this a lot. I think people assume that because lots of amateurs use PHP, it must be helping them be effective. This is not a safe assumption. A shoe does not help amateurs drive nails effectively, no matter how many amateurs you see using one.
For a better of idea of how amateurs interact with PHP, see http://stackoverflow.com/questions/tagged/php
The problem is, it often does take into account objective qualities.
The downsides of popular platforms are often ignored because they carry with them all the advantages of popularity: good support, a well-established community, a wealth of experienced people you can hire or draw upon.
These are not "objective qualities" of the technology, but real side-effects of popularity. In fact, you could say it's a technology's popularity that fools you into ignoring many of the objective qualities of the platform.
I think part of tech hipsterism (which, let's face it, is what you're talking about) is a rejection of this groupthink, and a return to true technological thinking. It's the ability to say "we don't care what's popular, we're just going to look at what works again and see where we end up." I think this very idea is considered 'cool' in the tech world because we tend to like people who think logically about their problems and don't just blindly follow what people have already done. We like people who look at lesser-used technologies (which all of the "cool" tech you listed above actually are) just on their technical merits alone. This is, perhaps, one reason they're considered cool; because it takes actual thought to break away from simply using what everyone else has used for years.
So I think you have noticed a definite trend, but I don't believe it's as purely social as you imply.
That said, "be aware that the future welfare of your family is relying on your decisions" is an argument that's used in so much Enterprise software that it's almost scary. Often the most popular, most entrenched, least risky, biggest company with the largest pockets wins because the CTO can't be blamed for fucking up that decision. It's an incredible driver of technological stagnation in the Enterprise world. It is great to think through your decisions to their far-reaching impact, but be thankful that all of technology is not driven by that kind of strictness, or we'd never use anything new.
Going with cool new things for everything is very risky. This is terrible for established businesses, it's great for startups with no legacy and no pressure to maintain inertia. There cultural differences are endemic to the realities of both types of businesses and aren't just the product of politics.
Just because a technology is "cool" doesn't mean that you're acting like a high schooler for using it. Nor does using non-"cool" technology make you an adult.
Truer words have never been spoken. When you think about it that way, these types of arguments about why language X rocks/sucks become trivial and unimportant.
I like to geek out over languages and technologies as much as the next guy, but there needs to come a time when you put your foot down and make a decision based on more important reasons than personal preference/feelings towards a language.
Cool-ness biases are perhaps not so easy to distinguish from justified ones.
I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating encounters with Redhat.
It's not that it is unusable -- anything which can be done on Debian can be accomplished on a Redhat box. It's death by a thousand little annoyances, which is exactly the argument against PHP, so I think it's an "apt" comparison (pun intended).
For example,
* How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
* While we are picking on Redhat's Apache, they also chose to pollute /etc with a bunch of crap which doesn't belong there. Symlinks to /var/log/httpd, /usr/lib/httpd/modules, /var/run, etc. So now, when I grep /etc for something config-related, I pause and think "why is this grep taking so long...", and then a bunch of crap from /var/log spews onto the screen. Thanks, guys...
* Still on the Apache kick, they decided to make the default permissions drwx------ for /var/log/httpd, with root as the owner. Really? Root is the only person who will ever need to look at those logs? Perhaps chgrp'ing to adm would be more sensible?
* Which leads to another problem... because they put their WSGI sockets in /var/log/http (WTF?), which is... only accessible by root. Wonderful, so now I have to reconfigure all of my WSGI processes to stick their sockets into some other location, like /var/run. On Debian, this "just works".
* The package maintainer of util-linux arbitrarily decided to remove cfdisk because it was a "pile of junk" (https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061 ). Really? Because every partition I've created on Debian for a decade worked just fine, using cfdisk...
* There is (was?) no "vim" package. On Debian, to install vim, you type "sudo apt-get install vim". On Redhat, you type "sudo yum install vim", then go search google for a few minutes, and then type "yum install vim-enchanced". Thanks, guys.
* Supported packages. At the time, the Debian package repository was something like 12,000 packages, while Redhat's was around 3,000. This meant that for any production system, you inevitably had to either compile and install lots of software by hand, or you had to rely upon the community (e.g. http://dag.wieers.com/rpm/) for pre-compiled packages, but now you've just thrown away the consistency and quality level which comes from e.g. Debian's Policy Manual, and you've introduced a rather gaping security concern into a "production" system. Wonderful.
That's all I can recall off the top of my head, but the gist here is that there are a ton of tiny little bad decisions which make Redhat suck, and there's simply no good reason for it. Its just a pile of annoyance.
Unfortunately, Redhat has somehow positioned themselves as the "enterprise" linux, so PHB's often make the technical decision to go with Redhat, completely ignorant of its technical deficiencies, dooming their employees to suffer the consequences.
Perhaps I'm jaded, but when someone tells me they run Redhat, I immediately assume they made that decision from a position of inexperience, and they simply don't know any better.
For historical accuracy, the HTTP server binary of the Apache project has been called 'httpd', compiles to 'httpd' in the source official distributions and is distributed as 'httpd' in the binary official distributions for ages, if not since day one.
Source: http://w3techs.com/technologies/details/os-linux/all/all (accuracy not entirely trusted, but it appears roughly accurate)
Hey now, we're all human. Even engineers. As soon as something becomes popular, it is no longer cool. Cool is the next popular. Cool is being different. That's just how things work.
Apache is slooooow (NGINX is cool!). MySQL is retarded (Postgres is cool!). PHP sucks (Python is cool!). Red Hat is lame (Ubuntu is cool!).
See a trend? The tech that sucks is the most popular and well established. The tech that's cool isn't popular. It has nothing to do with any objective qualities of platforms. It's all about being a part of the cool croud!
Remind you of high school much?
Now, if this is just a hobby, who gives a shit? Roll with the cool kids. If you're starting a business, be aware that the future welfare of your family is relying on your decisions. Think real hard about that.