5 ms·
80% of the web, a fractal of nope?
by derision 6y ago
80% of the web, a fractal of nope?
- 29athrowaway 6y ago80% of web servers is not the same as 80% of web traffic. I guess at least 80% of web traffic would go to the Alexa top 100 sites. How many of those run on PHP? There was a time where many if not most of them ran on PHP, but today many have migrated away from it for performance reasons.
- revendell_elf 6y agoCurious to know your experience with PHP. Do share.
- deleted 6y ago[deleted]
- smacktoward 6y agoOf all the complaints that could be lodged against PHP, performance is a weird one.
- kyriakos 6y agoPHP is quite fast actually. Its not Go fast but for an interpreted language its doing really well, runs circles round Ruby for example which was very popular for web apps.
- nickv 6y agoFacebook? (I know, it's technically HHVM but the language is basically PHP) Wikipedia? Wordpress? Tumblr? Large chunks of Slack? That's a lot of traffic. Fun fact: Companies typically leave PHP not for performance reasons (it's faster than Python and Ruby, for example) but because it's hard to hire people who know PHP since there's a strong bias against it. (To be fair, I was one of those anti-PHP people, but after seeing PHP7, Laravel, etc, I acknowledge it's vastly improved from the early 2000s).
- 29athrowaway 6y agoWikipedia and Wordpress have massive reverse proxy caches in front of their PHP servers. Those servers are the ones that handle most of the load. 99% of users only read articles and blog posts, which is content that can be aggresively cached. If the workflow was not as cache friendly, they would not be using PHP, for sure.
- deleted 6y ago[deleted]
- nickv 6y agoAgain, is it as performant as compiled/byte code languages like C, Java, GoLang? No. I'm not making that statement. This is why most real reverse proxy caches are not written in Ruby or Python. Does it compare favorably or equally to most interpreted languages? Yes, it is not an outlier in performance (and tends to be one of the fastest cause of all the tuning it's had from use at high load companies). And yes, large chunks of the code in these companies still, today, run PHP. I guarentee you Wikipedia's global editor activity is higher than you think it is. Same with Tumblr and Slack's entire channel communication pipeline (which was an offshoot from Glitch). It generally scales better than Ruby and Python. You can write shitty code in all of these languages and you can write clean code in all of these languages. And every language has it's warts (Python, which I LOVE and had a startup built around it, is FULL of these warts too).
- 29athrowaway 6y agoPHP has almost the verbosity of Java. For the same amount of effort you get less performance and access to inferior tooling for debugging, profiling, testing, static analysis, etc. The average person working on PHP applications cannot write a multithreaded socket server and do not understand TCP. They don't know how things work and what to do when they don't. Their mental model is based on self-evident truths such as "Laravel is good because Laravel is good" and "PHP is good because PHP is good", but as soon as you ask why, they cannot really ellaborate in terms other than "because it's good". It's a cargo cult.
- pamperson 6y agoprobably a fresh graduate who thinks python is a “good” language
- kyriakos 6y agoor maybe thats what the author is comfortable in. at the end of the day the outcome matters more.
- 29athrowaway 6y agoThat description does not apply to me, and while I know Python, I don't use it. I do however have respect for Python. PHP would benefit from the Zen of Python: >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!