22 ms·

Where to begin indeed! > - No proper connection pooling with circuit breakers. PHP has had a "shared nothing" architecture since the very beginning, that incl

Where to begin indeed! > - 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 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.

echelon 6y ago
> but pretty hard to proceed with some code that works with a DB when the connection can't be established 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.
- alphadevx 6y ago
  > When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc. You would query those first surely, before loading the DB? Regardless, I've been using Redis and Memcache for years from PHP, so mute point. > I use multiple threads in a single request flow frequently. So how do you track those? And for how long do they live after the parent request has been processed, or do they block the parent? Gets complicated quickly. > It's ugly and inconsistent, takes time to memorize, and leads to errors. Rasmus will admit the same, but he will also admit he does not care (I've seen him say this during a talk). Nobody bought your product because it had beautiful, consistent code. > This limits you to writing basic CRUD. And so many other languages offer this. 99.9% of web apps are CRUD.
  - missosoup 6y ago
    Just FYI since you've done it twice and might want to know, it's not mute point. It's moot point.

echelon 6y ago

> but pretty hard to proceed with some code that works with a DB when the connection can't be established 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.

alphadevx 6y ago
> When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc. You would query those first surely, before loading the DB? Regardless, I've been using Redis and Memcache for years from PHP, so mute point. > I use multiple threads in a single request flow frequently. So how do you track those? And for how long do they live after the parent request has been processed, or do they block the parent? Gets complicated quickly. > It's ugly and inconsistent, takes time to memorize, and leads to errors. Rasmus will admit the same, but he will also admit he does not care (I've seen him say this during a talk). Nobody bought your product because it had beautiful, consistent code. > This limits you to writing basic CRUD. And so many other languages offer this. 99.9% of web apps are CRUD.
- missosoup 6y ago
  Just FYI since you've done it twice and might want to know, it's not mute point. It's moot point.