I would hazard a guess that if PHP was not so hated (like the one kid on the playground that everyone decides to mock because everyone else is, and because it keeps attention off of them) devs who are familiar with and articulate in PHP would not hesitate to start new projects with it.

Anyways, my personal perspective is server-side is becoming a smaller and smaller piece of the web. Any reasonably designed language should be sufficient. Unless maybe if you're Google or Microsoft, or deal heavily with extremely large datasets such as BigData / Analytics / Machine Learning companies. And even then worst case scenario you just throw all the data into AWS RedShift or something like that.

If you're writing an OS, building a Linux driver or writing a memory management library I'd certainly recommend avoiding PHP :)

BTW, I've run side projects where PHP (before 7.*) sufficiently handled databases with 100's of tables containing billions (yes, that's a 'B') of rows each on a single $250 laptop. That includes jobs running relatively heavy analytics jobs on those tables. My guess is if the company was spending money to get appropriate talent to handle their infrastructure they might be able to make PHP work well for them without a lot of trouble. And by that I don't necessarily mean they have untalented people. I'm saying if they're truly "fluent" in PHP, or are willing to put in the effort to learn PHP, it shouldn't be hard to do.

No programmer can expect to use just a single language over their whole career. They might have career stability if they choose that but very risky stability.

  - it's easier to find PHP programmers
  - you get a lot of mature frameworks with huge communities
  - most of the time you don't need fast but fast enough

The problem is that PHP needs to bootstrap the entire environment for every request (minus some more or less efficient caching) which may be OK for monolithic applications but as soon as you want to build an app on HTTP2 that runs many requests, it will just always feel sluggish. And for this symfony already cheats massively by merging all class files into one huge bootstrap.php file etc. PHP just wasn't made for large applications.

Everyone else is just taking advantage of a few milliseconds here and there (for example compiled language vs interpreted language) that might "appear" the language is better suited to the task, but ultimately only are as good as the architect(s) of the system made them.

I disagree PHP the language is deficient in any significant way that would prevent anyone from building large, modern web apps with it.

Personally I avoid ORMs and write SQL, better control and better performance.

Compare this to a Java Application using JPA and JAX-RS with >50 model classes and >10GB data which gives response times of <10ms with debugging enabled (OK it uses more RAM, but meh).

When you use proper opcode caching, you avoid the startup hit.

And having a generous amount of RAM usable as disk cache also helps in framework-heavy projects - the more files can be cached in RAM, the less PHP has to hit the disk on require/include.

Another question, with those modern PHP frameworks you are already learning and applying almost every concept that you can use with (let's say) JAVA. Then why not to use that powerful platform which inspires PHP? It is like you have driving licence for a truck and you can drive a truck almost perfectly after 3 months of practice, but still you prefer your old minivan to carry 10 tons of load. The minivan was not designed for 10 tons of load but there are some modifications allowing that, but if you spend 30% more fuel.

Don't come with the argument of "php is easy". It is as hard as other similar languages.

Large PHP frameworks I think is starting to reach end of line. Seems like a micro framework trend has started with Zend Expressive and similar middleware based frameworks.

There was a trend of making PHP into Java, I think that is the wrong path, as you say, Java already exists. That trend also existed in JavaScript a long time ago. Seems like a natural instinct by some developers to do so when trying to create structure from a chaos like world.

Much better to build on PHP strengths. Dynamic, stateless, fast development cycle.

In a setup with nginx, php-fpm and symfony here is how i understand the whole process.

  1. A request hit nginx
  2. Nginx parse the request and send it as fastcgi protocol specify to
     php-fpm.
  3. Php-fpm looks it's pool of php processes if there is none
     available, it starts a php process (so some code is run).
  4. Php-fpm fill the $_GET,$_POST etc... variable of the running php
     and give it a file to execute.
  5. The php process check if the file is in opcache load the bytecode
     from it otherwise compile the file to bytecode and store it to
     opcache.
  6. The process run the script and write back to php-fpm who write back to nginx.
  
  So now more on 6. from the point of view of a Symfony app.
  
  1. the app.php will include an autoloader, this mean during the
     lifetime of the php process every time a new
     \Some\Class\Or\Function\Or\Whatelse is encounter the autoloader
     code will be run. To mitigate this composer could generate an
     autoload that is an associative array of \ClassName\And\The\Like =>
     filename.
  2. Then it include the bootstrap.cache.php this file is a
     concatenation of the Symfony classes (all or the most used) in
     order to reduce autoloader calls.
  3. Then it create the kernel the it load more file (from app/cache)
     like the service container definition+configuration and the
     routing (and maybe more stuff but i don't know).
  4. Then it put $_GET,$_POST etc... on it's own abstractions
     (HttpFoundation\Request etc...).
  5. At this point the bootstraping is done.
  
  And i also want to remind that a class declaration like "class House
  {}" is a code, that create a datastruct that has to be run on every
  request, this is also what people call bootstraping.
  
  The bootstraping is take seriously enough to have :
  
  1. composer -o (generate the associative array)
  2. bootstrap.cache.php
  3. the whole app/cache directory of symfony which i find pretty
     terrible as comp. sci. point of view (choose a limited language and
     build compilers to work around) even if they do a great job at
     error reporting.
  4. php-fpm pool of thread
  5. opcache

We have pretty good success just using a user space cache, like apcu or memcached, along with the bundled opcache.

It does still have some bootstrap overhead with each request, but it's not become a performance barrier.

I suppose this is different at a certain scale, but I'd wager that's a pretty small percentage of real world use.

PHP right now is in an interesting space: It's very stable, it has an enormous ecosystem, it has some extremely strong frameworks and tooling, the syntax has stopped being egregiously bad, it's starting to get quite fast, and the PHP request/response model is very attractive for some purposes, and avoids an entire class of bugs which crops up with, eg, nodejs.

If you're doing something where PHP is appropriate (which is a lot of stuff), and you're familiar with it, you're going to be extremely productive. Switching to golang (especially if not familiar with it) is like deciding that instead of going to the supermarket and buying a loaf of bread, you're going to buy a farm and figure out how to grow wheat. You have the ability to end up with a better product, but there's no promise you will, and it'll be a lot more work.

> Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow

Of course if the client requires you to use golang, then sure, use golang. But it makes me wonder about the design the client is imagining. If your web server is trying to do very intensive calculations as part of the request/response cycle, you're probably doing something very, very wrong. But if you're not doing that, why does your need to do intensive calculation impact your choice of frontend? What's stopping them from having a lightweight frontend which queues up jobs in a task queue, and then have workers written in golang or C or whatever? And then maybe a websocket server to feed results back to the browser as they arrive? Where did they get the idea that a project needed a single language for every feature?

The up-side to PHP is that it is super-flexible. The down-side to PHP is that it is super-flexible. You can work fast with it, which also allows you to be extremely sloppy with it. The programmer has to wield all the discipline, because the language sure isn't going to help.

The up-side to Go is that Rob Pike is older, wiser, and learned all of the mistakes of C and C++. Rather than have it be all things to all people, he made some very opinionated design choices with crystal-clear trade-offs. More code will have to be written. It will be in an imperative style. Errors will need to be handled explicitly rather than through a catch-all exception. Elbow grease! Elbow-grease that results in more robust code that is easier to understand and reason about.

So, why PHP? Sometimes quick and workable is preferable to slow and great.

So if Go looks better to you, you should use that.

  - easy deploy 
  - large community
  - anyone can code PHP and become productive fast
  - No built in shared state. 
  - PHP is available almost everywhere
  - proven
  - simple development cycle