[muglug]

> PHP is a nice language but is having trouble keeping up with modern languages

It's only "having trouble" because it can't change its API from month to month to match whatever's in vogue. A majority of the web still runs on some variant of PHP, and that guarantees that it's not dying anytime soon.

More broadly, it seems the author wants to create a version of PHP that's not focussed on web requests, which is sort of the entire point of PHP.

[wwweston]

I might even go so far as to say that the contention isn't true. In fact, these days I tend to assume the word "modern" is a developer thought-smell. Unless its user can explain what they mean by modern, it's best to assume it's a set of personal aesthetics informed largely by available fashions/habits in the first half decade of a developer's career (which can be fine, it's just the term modern carries waaay more weight than it should).

( -smell can also be a thought-smell, but that's another discussion.)

I'd guess the author means "modern languages have a reasonably simple concurrency paradigm supported by language or standard library primitives," which would be about the only reason other than the interest in the task itself I can imagine reimplementing PHP in Go. I wouldn't buy that definition myself (and as the parent says, it's less clear whether it's the right fit for PHP) but it's a place to start in addressing the relative merits the project might actually be claiming.

[jchw]

It feels like you are downplaying decades of genuine improvement in web development under the guise that it's all just fashion, flavor-of-the-week stuff that has no substance. I get that people have an inverse reaction to hype, but I am disappointed that this is the top comment.

There's a reason why the world moved on from CGI, even PHP moved on from CGI - and yet, its request model is still based on CGI, executing a script for each request. People are still relying on a webserver to rewrite URLs because PHP doesn't have the concept of an application server with a router. How is that superior to the more modern paradigm?

Despite this, the most largely used pieces of PHP software, MediaWiki, Wordpress, etc. tend to use things like the front controller pattern that actually invert the old CGI model into something more like what you would see with application servers in Ruby on Rails, Django, even Go to a degree.

[muglug]

> its request model is still based on CGI, executing a script for each request

And it turns out to work incredibly well for the most part. It's serverless by design!

> People are still relying on a webserver to rewrite URLs because PHP doesn't have the concept of an application server with a router

Again, I don't see how this is a problem. Routing is likely to be the most trivial part of your app, but it's also tied to business logic and should (IMO) be part of the checked-in code.

[jchw]

>And it turns out to work incredibly well for the most part. It's serverless by design!

Worked incredibly well compared to what? CGI was a performance nightmare, forking per request. CGI and FastCGI have both been a security nightmare. HTTPoxy, Shellshock, Pathinfo, and more. Setting up PHP correctly is cumbersome and depends on a complex interaction between sometimes confusing php.ini options and fairly complex configurations with your webserver. Check out, for example, this article on configuring PHP properly with Nginx:

https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...

So other than that, yes, it worked. Incredibly well? Not compared to application servers which don't have the kinds of vulnerabilities and configuration complexities caused by the weird impedance mismatch between webservers and FastCGI workers.

The jab about serverless is really condescending and unrelated, but I feel it necessary to point out that I am not really especially a proponent of serverless as it is today. I much prefer long-running application servers. PHP-FPM gives you a bit of both worlds, a combination of them that is far from ideal in my opinion.

>Again, I don't see how this is a problem. Routing is likely to be the most trivial part of your app, but it's also tied to business logic and should (IMO) be part of the checked-in code.

I am having difficulty responding to this because I think you misunderstood what I meant. I do think the routing logic should be part of the code. Which means, not part of the webserver configuration. If you're using Nginx, which is the server I currently use with PHP, checking your rewrite configuration in with your code is difficult, because there's no `.htaccess` mechanism like Apache, and so you have to deploy the configuration separately.

[muglug]

> Setting up PHP correctly is cumbersome and depends on a complex interaction

One of the reasons PHP is so successful is that (in most cases) you don't have to set it up beyond the default installation. But when you need something done "correctly" it takes time. The same is true for every other server environment, where what's correct for you isn't necessarily correct for me.

> If you're using Nginx

I don't have any experience using PHP with Nginx - we use Varnish at $dayJob, alongside some very basic non-PHP routing e.g. foo.domain.com goes to one set of servers, bar.domain.com goes to another. Everything else is done in PHP, with a simple wildcard .htaccess pushing everything to that front-controller you were talking about.

The point I'm trying to make here is that for most web request use-cases, PHP can help you get what you want. But if there's a paradigm you prefer, use it. If you control the stack, the world is your oyster.

Edit: the article you posted is from 2011. It's not entirely fair to say PHP is bad, and use evidence from 7.5 years ago to back up your claim.

[jchw]

>One of the reasons PHP is so successful is that (in most cases) you don't have to set it up beyond the default installation. But when you need something done "correctly" it takes time. The same is true for every other server environment, where what's correct for you isn't necessarily correct for me.

I disagree. I think PHP was so massively successful because it was part of the mighty LAMP stack. The LAMP stack wasn't great because it was free of configuration, it was great because anyone could pick up an existing setup and just use it. A non-technical person could get a Bluehost or Hostgator account and get Wordpress running in under an hour.

But once you move from shared hosting to VPSes, the plug and play fun goes away. At reasonably moderate traffic, you have to tune things and debug weird issues. And debugging it, in my experience, is actually very challenging.

The best part of the LAMP stack today is that it offers a very quick way to get a good development environment. Since scripts are read off the disk, you get "auto reload" for free. That is nice, but given how mature other development environments have become, it's no longer a huge selling point to me.

Is the ease of use of the LAMP stack worth the negatives of PHP as a programming language? In my opinion, no. To me, it's only really 'yes' if you already have a very large PHP application, or you are writing software for people running LAMP stacks to deploy.

>I don't have any experience using PHP with Nginx - we use Varnish at $dayJob, alongside some very basic non-PHP routing e.g. foo.domain.com goes to one set of servers, bar.domain.com goes to another. Everything else is done in PHP, with a simple wildcard .htaccess pushing everything to that front-controller you were talking about.

If you're using .htaccess, it sounds like you're probably using Apache as an HTTP server. Varnish is a caching server.

>Edit: the article you posted is from 2011. It's not entirely fair to say PHP is bad, and use evidence from 7.5 years ago to back up your claim.

I never said PHP was bad. I am making the case that the application server paradigm where you have long running programs handling requests is better than the CGI and Fast-CGI paradigms where you run scripts per request. You can put band-aids on it, like caching very aggressively, but at the end of the day you will never get the 'free' amortization of per-request costs like you will with a proper application server.

That said, I totally think it's fair to use evidence from 7.5 years ago. A, these configuration difficulties exist today, and my proof is that I also have them today. B, Track record matters! PHP and PHP-FPM have been around for decades. Having constant security issues is a sign of endemic issues, such as what we saw with software like Wordpress or Drupal.

[vlunkr]

> it can't change its API from month to month to match whatever's in vogue

This is true of every language used on the web. That's why it's important to start out with the right choices, which in many instances PHP did not do, and is slowly trying to recover.

[jimnotgym]

A majority of the web runs on one of a handful of programs that use php...WordPress, Magento...

[tgtweak]

While true, there is still a tremendous amount of the web that is powered by php and not using WordPress or Magento.

Facebook, Yahoo, Wikipedia, even Google.

[baroffoos]

Facebook forked PHP to make Hack to try and make PHP usable.

Yahoo is yahoo.

Wikipedia wouldn't have the resources to change anything.

Google has a wiki page for their developers telling them to never ever use PHP for any google project.

[wwweston]

> Facebook forked PHP to make Hack to try and make PHP usable.

Facebook clearly found PHP usable before they created Hack, otherwise they would (a) not have bothered and (b) may well not have existed in the first place.

The accurate statement is probably closer to "FB created hack to adapt to performance demands at an unusual scale and add some additional typing discipline bringing additional order across a large engineering team."

[swsieber]

I'd take it one step further:

At Facebook scale, performance gains have huge returns (adding typing can improve pefromance), so they try to improve all parts of their infrastructure, not just PHP.

For example, Facebook's bolt for native code: https://code.fb.com/data-infrastructure/accelerate-large-sca...

PHP probably did have more low hanging fruit than say C, I'll give them that.

[partiallypro]

Just because Google doesn't have a use for PHP doesn't mean it has no use or that it's dated or having "a hard time keeping up." Why would Google want to use PHP when it doesn't have a core competency that uses it?

On the other hand Microsoft does use PHP in some cases, where it makes sense, like company blogs. What's wrong with that? Nothing. The right tool for the right job. People that hate on PHP are usually people that over engineer things. Why build something like Wordpress in .NET or Node.js...when you don't need that, because you already have Wordpress and it works fine for a small site or blog? People will spent 10x the amount of time trying to -not- use PHP on a simple project than to use that time doing something else.

It's like this new "let's containerize everything" movement. Ok, you just spent an hour setting up something that would normally take 5 minutes, and you now have access to a bunch of features your little app will never ever use. Congrats.

No one is saying use PHP to build a super complex webapp, (though you could do that if you wanted!) But for small project PHP is very hard to beat when it comes to time/benefit. Right tool, right job. Simple. Biggest complaint I have against modern developers is the tendency to make a simple thing complex because it's en vogue to use X, vs Y. Gotta build this small web app with 50 users and no need to scale, better build in Node and Kubernetes. So laughable.

[nicoburns]

There's also Laravel, which is more popular than both Django and Rails on a worldwide basis (https://g.co/trends/9CGj5). Rails and Django are more popular in the US where I hear PHP is not very popular...

[ksec]

Interesting, I have seen a surge of Laravel + Vue.js in recent projects. And many companies wanted to move back to PHP / Laravel from Ruby Rails / Django.

[muglug]

> Google has a wiki page for their developers telling them to never ever use PHP for any google project.

I didn't know that, but it makes sense - the things that PHP's good for (getting a web-based service backed by some sort of datastore up and ready to receive requests) are not the things that Google (on the whole) cares about.

Google instead cares that the thing can be improved and maintained by your colleagues, few of whom know PHP.

[wolco]

Those facebook improvements made there way back into the core.

Google might be able to move quicker if they allowed php. Facebook killed them in social. The type of products google can offer is limited by this decision.

[koudos]

Not sure PHP is the reason reason why Google failed at competing at Social

[Ayesh]

It is not.

[baroffoos]

Google+ did not fail for technical reasons. Everything I saw about it was technically better. It failed for social reasons, facebook already exists and has everyone on it.

[ksec]

It didn't failed for Social Reason, it failed because it was an inferior product for the mass. Facebook succeeded because its concept is simple enough for even your GrandMa and Dad to understand.

Google+ was designed by geeks for geeks.

[TigerHimself]

Facebook was here already when Instagram, Twitter, Instagram, Snapchat became popular

[Operyl]

HHVM can't make its way entirely back to core, and is in fact completely separating from PHP entirely now[1]. If I recall correctly, while PHP7 implemented better op-caching, it has _not_ implemented JIT compilation yet.

1. https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html

[acomjean]

This is true. But HHVM lit a fire under the php devs to get php7 out the door with significant performance improvements. (php6 never saw the light of day). Php has improved so much with the 7x releases.

[muglug]

It hasn't - a JIT compiler (if it comes) will come in PHP 8.

[jchw]

Employee of Google here... really? Where does Google use PHP?

[mholt]

> a version of PHP that's not focussed on web requests, which is sort of the entire point of PHP.

But even for web requests it's terrible. Or at least, it was, last time I used it years ago. Couldn't really do any long-running tasks in response to an HTTP request, or load a single data set into memory to share among all the HTTP requests over the lifetime of the server. (Maybe you could, but I couldn't figure out how.)

I'm quite happy that I haven't touched PHP in years. As fun/cool as this project is, there's nothing I miss from PHP that isn't present -- or even better -- in Go.

[nicoburns]

PHP has gotten a lot better. New APIs have been added on top of features like classes. And many of the worst of the older APIs have been deprecated.

It still works on the "new interpreter per request model". But that has advantages in the multicore world: everything is thread-safe by default, and will scale to N cores without any extra work (for shared state people tend to use something like Redis).

It's by no means perfect. But if you stick to the modern bits and use one of the nicer frameworks (like Laravel), then I think I'd prefer it over something like Ruby.

[debaserab2]

> use one of the nicer frameworks (like Laravel)

Yikes

[cityzen]

And?

[muglug]

> But even for web requests it's terrible

Maybe you have specific needs? At Vimeo it runs reasonably well, with median response time around 30ms.

> Or at least, it was, last time I used it years ago

Ah, PHP 7 was released three years ago and made some massive improvements to performance.

> Couldn't really do any long-running tasks in response to an HTTP request

We add something to a queue, and handle those tasks offline. Pretty simple.

> or load a single data set into memory to share among all the HTTP requests over the lifetime of the server

apc_store does that: http://php.net/manual/en/function.apc-store.php (it's part of a very popular extension)

> I'm quite happy that I haven't touched PHP in years.

Cool, it's not for everyone and all use cases. But it's always there if you need it.

[JadeNB]

> A majority of the web still runs on some variant of PHP, and that guarantees that it's not dying anytime soon.

The same is true of Perl, but (depending on your definition of "not dying") it's not clear that Perl isn't dying.

[wolco]

PHP is growing these days. Some of the hip crowd are coming back, small business never left and globally it is gaining as more developers come online. PHP offers so much so easily it's hard to replace.

[cglace]

Why choose PHP over python, node, ruby, elixir, go, etc. There are just so many great choices that offer just as much and more than PHP. I get that PHP has made major strides over the years. I just don't see why you would choose PHP for a greenfield project.

[claudiawerner]

One component is the fact that it comes out of the box on a great many hosting providers and it's part of the old "standard" LAMP stack. You don't have to set up any reverse proxy crap and the architecture is simple enough - you access a .php file which is really just HTML with some embedded code and it interprets the file. The concept couldn't be any closer to JavaScript which I suspect has attracted so much attention from beginners just because it's everywhere on web clients, just as PHP is everywhere on web servers.

[insulanus]

Well, my guess is that PHP offers a lot more to the beginner.

When you've been doing this a while, you can appreciate what e.g. Python gives you in structure, maintainability, and lack of foot-guns.

But when you're still in the "how does this work? Why won't this work? It worked!" phase, having less boilerplate, and fewer non-problem domain concerns (types? modules? tuples? Say what you mean, Old Man!) might be really valuable.

I think the best thing I remember about PHP is probably its online manual. Each library function had a few full use cases underneath.

[cglace]

> But when you're still in the "how does this work? Why won't this work? It worked!" phase, having less boilerplate, and fewer non-problem domain concerns (types? modules? tuples? Say what you mean, Old Man!) might be really valuable

However, modern php isnt being sold as index.php and a mysql connection. It's Doctrine, composer and laravel/symphony. Which have their fair share of boilerplate.

>I think the best thing I remember about PHP is probably its online manual. Each library function had a few full use cases underneath

The problem with PHP is that you need the online manual everytime you want to use a function because the argument order is so inconsistent.

[Mave83]

best documentation in my opinion