A look at modern PHP

> - No proper connection pooling with circuit breakers.

PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design.

> - No proper multithreading (that works in web environment) or parallelism in general.

I once asked Rasmus about this face-to-face, during one of his presentations, specifically his thoughts about the pThread extension (https://www.php.net/manual/en/intro.pthreads.php), and he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.

> - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server).

Well, it depends on your code of course, but pretty hard to proceed with some code that works with a DB when the connection can't be established, so proceed with what exactly other than error handling? Seems like a strange example. And as mentioned above, no (excluding optional pThreads) support for asynchronous threads in the language, so...?

> - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to avoid native code as much as possible. This means that code is not memory safe, and understanding or contributing is close to impossible.

Ok now you have just thrown away one of the main benefits of PHP. Remember, Rasmus is a C programmer, not a PHP programmer, so he wanted to leverage that HUGE library of existing C-code from his new scripting language, from the very beginning, deliberately by design.

> The reason for this is because PHP doesn't support many things that are expected in any other language.

Yes it does, via the C-extensions, see above.

> PHP C API is hard to understand, hard to use, and documentation is subpar.

Yes programming in C is hard.

> - There is no way to easily share memory between processes. You have to rely on APCu (hack), because this cannot be implemented in PHP.

Deliberate design choice, "shared nothing architecture", stateless between requests, as above.

> - Did I mention that almost anything can block? ODBC? PDO? Some 3rd party library? Even set_time_limit cannot help you here. Handling this gracefully is close to impossible.

Yes because each request is a synchronous thread, as described above above. By design.

Lots of languages have HTTP tools and frameworks, but not many of them are even comparable in scope to Symfony or Laravel. Out of curiosity, can anyone point me at some frameworks in other languages that have the following things built-in?

* Route matching and dispatch

* URL generation (generate a URL for some route) including signed and temporary URLs

* Middlewares

* Abstractions for dealing with incoming HTTP requests (getting headers, body, uploaded files etc.)

* Abstractions for creating and sending HTTP responses (headers, body etc.)

* CSRF protection

* Database drivers for a couple of backends (MySQL, PostgreSQL, SQLite etc.)

* Database migrations

* Database seeding

* Views/HTML rendering

* Logging capabilities (configurable backends like rotating log files, syslog, Slack etc.)

* Sessions with different storage backends (filesystem, Redis etc.)

* Request validation ("this field is required, has to be a string, between x and y characters long" etc.)

* Translation and localization

* Broadcasting through WebSockets

* Caching with a couple of backends (filesystem, database, Redis etc.)

* Email sending with a couple of backends (SMTP, Mailgun, SES etc.)

* Notifications with different channels (Email, SMS etc.) and backends (SMTP, Mailgun, Twilio etc.)

* Job queues with different backends (database, Redis, SQS etc.)

* Scheduled jobs

* Authentication (different flavors like regular sessions, API tokens etc.)

* Authorization

* Hashing

* Encryption

* Query builder

* ORM with relations between objects, JSON serialization etc.

* CLI commands with option/argument parsing, colored output, progress bars etc.

* Events, including async handling of events

* File storage with a couple of backends (local filesystem, S3 etc.)

* Pagination

* Payment integration

* Full text search with different backends (database, Algolia etc.)

This is basically the feature set of Laravel, I probably missed some things too.

And I don't mean "oh yeah I'm sure there's a library for that" - I mean fully integrated, first-party, tested, dead simple to use and available by default.

Maybe I'm wrong, but I seriously doubt this just exists in any language.

Maybe you are not familiar with PHP multithreading in recent times but I have been using https://github.com/krakjoe/pthreads and works perfectly. No process forking.

When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc. You probably have background threads that do cache invalidation, queue management, etc.

You frequently have to be more reliable than your database.

> he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.

I use multiple threads in a single request flow frequently. Dispatching requests to other services or data stores, updating in-memory caches or queues (not Redis, but living within the app itself), etc. It's an important tool.

> Ok now you have just thrown away one of the main benefits of PHP. Remember, Rasmus is a C programmer, not a PHP programmer, so he wanted to leverage that HUGE library of existing C-code from his new scripting language, from the very beginning, deliberately by design.

Good for him. I don't see why that matters for anyone else. It's ugly and inconsistent, takes time to memorize, and leads to errors.

> Yes because each request is a synchronous thread, as described above above. By design.

This limits you to writing basic CRUD. And so many other languages offer this.

There is no shell accessible on these servers, it's on the project to include all dependencies. Composer in this world is strictly not for users, but only for developers. That's a good thing.