Years ago (1999?) one of the early PHP bloggers had written that PHP was good precisely because of 'shared nothing' architecture. There was no shared memory, no threads, etc to trip you up.
Years ago, and colleague bitched about PHP, and one of the issues was 'no thread support'. I went to pick him up for lunch one day, but he couldn't make it - 'debugging some threading issues' (in either java or c++ - can't remember which one). I... didn't quite bite my tongue, and, while I know 'different tools for different jobs' makes a lot of sense, I also know many people have made more work for themselves by explicitly avoiding even greenfield projects in PHP because... well.. because it's PHP.
Also, from what I gather, PHP will be getting real async support in a couple years, which may throw some of the 'ease of thinking' arguments out the window a bit.
You have to have some pretty exotic needs to want to use them, but threading does exist, and I’ve built a multithreaded php app using it.
Also, the pcntl functions don't provide multithreading primitives, only multiprocessing (fork)
Edit, looks like there is also a pthreads extension
While "writing a daemon" is pretty common, I've never seen a daemon written in PHP (I'm sure they exist, I've just never seen one), so I would call that an exotic use-case :P
The reality is almost certainly far simpler. PHP started as a suite of tools for writing CGI pages , which have the same property mentioned. As with many things, that early design choice has followed through and led to continuing to execute PHP in similar ways as CGI did way back then.
I think the 'rll' user is Rasmus, who started PHP. I think he would be the best person to cite re: intentionality.
The fact that PHP died after every request made everything other than the HTTP use-case quiet a pain to implement.
That's one reason why it got pwnd by Node.js, I think.
It required me being curious about why a random commenter would make such an authoritative (but not backed up) statement, remembering PHP's creator's name and making the connection that their username may be related to it, then reading his Wikipedia page and digging through his comment history to find a couple from 2015 (about UWaterloo) and then 2013 (about his age!) as supporting evidence!
Now I feel creepy.
Edit: (but really, it's nothing compared to the awesome "Did you win the Putnam" response https://news.ycombinator.com/item?id=35079)
The only "perfect sandbox" I can think of for CGI programming is something like Unlambda (pure functional, except for monotonic reading of input and writing of output)
I do not think PHP had design decisions until ... much, much later than day one. I would cautiously say even PHP 4 is more than a bit haphazard and PHP 5.0 I definitely remember as an alpha quality release, 5.1 as beta and 5.2 as stable. Design, I think, started to appear with the later stalled PHP 6 attempt and so mainline 5.3. The first one I remember that can be called a conscious design decision was deferring $this support in closures to 5.4. Correlating with my memories is the first release to appear under the "Implemented" headline on https://wiki.php.net/rfc is 5.3 indeed.
In PHP, when your page is done processing, the process is killed and all the connections, file handles, or resources it had open will be closed.
The more I work with .Net, the more I get to appreciate the things in PHP I had taken for granted.
I wrote about this a year ago: https://idiallo.com/blog/php-fast-debug-time
In addition to $_SESSION hell, lots of custom PHP applications end up with extremely complex and convoluted MySQL tables dedicated to storing what would typically be global application state.
Both of these can lead to difficult-to-debug performance issues, race conditions, and especially security vulnerabilities.
Global state is going to happen, so languages/libraries should provide mechanisms that make it easy to state and enforce strict invariants on reads and writes to global state.
But sessions are available in other languages as well:
Also, IME even good PHP programmers suffer from the "MySQL-table-as-global-runtime-state" syndrome. And it's at least as bug-prone as storing global state in an ADT.
We're setting the bar pretty low for what's a good thing in a language here.
PHP with fastcgi reliably and quickly resets the php process to freshly launched state after every request, and very few languages can manage that trick in a production context.
For example Gradle (a java build system) runs a daemon that hosts a bunch of tasks that run and die.
Docker does it with images.
The browser does it with tabs.
Php achieves it with the help of server components. That is fine, but I wouldn't advertise it as a feature.
This property is definitely one of the things I love about PHP -- when the request is done, everything is thrown away. This encourages you to do the minimum amount of work to get your HTML (or whatever) out the door. I'd like to say it forces you, but it doesn't really -- I've seen plenty of 'lightweight frameworks' that mess around for 50 ms creating cathedrals of objects that just get thrown away on a hello world page; if you do the minimum amount of work, you can get pages out the door pretty quick. Layering and abstraction can solve a lot of things, but it can't solve wrong abstractions.
What I find ironic is that creating the illusion of state in php is an absolute pain without a framework, which again applies to most language/server combos I've tried.
Guidelines, good/bad practices and patterns are merely suggestions, enforcement is king.
Still, I remember having to cache initialization state in PHP because it took too long to build it on every request. That's when the model breaks down and you prefer a server with state.
I also had this problem, but fortunately, I could always buy my way out of the problem better hardware and maybe one afternoon of optimization.
I finally shut down the last of my PHP side projects because of pervasive security issues and a dwindling/dead community. I recently reinstalled one of those sites on a DO droplet. Getting the right versions of everything took an entire weekend, but I eventually succeeded. The droplet had way more RAM and a faster CPU than I had access to back in the day.
But holy hell those pages still loaded so slowly. I probably didn't notice at the time because internet connections were so much slower and waiting for an HTTP page with a few images to load was normal. But those load times would be absolutely unacceptable today.
Years ago (2005? 2006?) I had a lot of trouble running PHP processes for any serious length of time, but don't now (7.1 mostly)
I didn't try too much daemonization around ~2005, though Schlossnagle's "Advanced PHP Programming" (2004) did have a whole chapter on daemonizing and the pcntl functions that made it possible.
As much as a programming language gets more popular, and more programmers write code with it, you see more "quick-and-dirty" solutions around.
As Java started to become even more popular cos of Android, I see more crappy code written in Java.
As much as Scala codes were clean when only early adapters would pick it, now I see more "quick-and-dirty" code because simply there are more codes out there.
The main problem is the majority of developers are not disciplined/experienced/responsible enough to keep their code organized and learn how to do it.
And that is just how it works with everything we do. Majority of people also don't keep their house/room/desk clean and organized.
As soon as any programming language hit the top 5 popular programming language, you have enough example to complain about it.
As Bjarne Stroustrup said, there are only two kinds of languages: the ones people complain about and the ones nobody uses. Having invented C++, he should know.
One thing many people misunderstood is that "PHP are for newbies".
No, you need to have some serious knowledge on PHP to be able to navigate yourself away from all those pitfalls that language provided. For example, use ===, be careful with "0e123" etc.
All those pitfalls combine, is annoying enough to out weight most the good things that PHP also provide.
Sadly, PHP developers still use bad coding practices. For example, one of the popular PHP OOP frameworks, Symfony, makes things like HTTP Request or logged user a global variable by storing it in DI container. What about incapsulation and concern separation? The code breaks if you run it from CLI. PHP should not copy bad ideas like this from Ruby.
If you are starting a new PHP web app and you expect to grow beyond a toy project, I highly recommend starting by using the Laravel framework. Laravel provides so many useful things and it encourages good separation of concerns and code organization. But it is flexible enough to get out of your way if you need it to.
If you look at any code example here  you will see that global variables are used everywhere.
But globals are not universally evil. Laravel uses globals very thoughtfully. Having used the Laravel framework for many years, I agree with many of the choices it has made.
Additionally, Laravel does not force you to use Globals. See https://laravel.com/docs/5.6/requests to dig a little deeper.
I guess you have tried Symfony, haven't you?
PHP really baits people into making very fragile software. It's very hard to write good PHP. It's hard to write good C, too, so rather than frame it as an attack, realize that it's a long rope with which one can hang himself.
I also think a lot of the bitching about PHP is mostly because newer programmers are just repeating what they heard with the fervor of someone who doesn't work in PHP regularly.
Does it have problems? OH HELL YES. So does every language. Are the problems ever going to be fixed? OH HELL MAYBE. Is it the perfect hammer for every nail? OH HELL NO.
I work with what I know and I live with the problems because that's what I know. If I need new features, I'll work in another language, maybe.
No language is without issues. Except Python. Python is perfect.
well put BTW