6 ms·

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. -

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. - 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). - 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. The reason for this is because PHP doesn't support many things that are expected in any other language. PHP C API is hard to understand, hard to use, and documentation is subpar. - There is no way to easily share memory between processes. You have to rely on APCu (hack), because this cannot be implemented in PHP. - 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.

norswap 6y ago
Something being written in C does not mean "understanding or contributing is close to impossible". That's as much of a boogeyman as I've ever seen.
- lostcolony 6y ago
  It is when discussing the merits of a given language, and the assumption is "a person knows the language under discussion". I.e., for the criticism to not apply in this context, a solid PHP developer...has to also be a solid C developer. Given the context is "using PHP", the former is likely, the latter, not so likely. Exactly how likely I don't know (I don't use PHP, so don't really have an opinion anywaay), but most discussions I've seen around PHP don't also presume the adoption of C.
alphadevx 6y ago
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.
ainiriand 6y ago
- No proper multithreading Maybe you are not familiar with PHP multithreading in recent times but I have been using https://github.com/krakjoe/pthreads https://github.com/krakjoe/pthreads and works perfectly. No process forking.
- kangoo1707 6y ago
  still, no proper multithreading, in comparison with Java, C#, Elixir...
  - ainiriand 6y ago
    Define proper please.
    - Piskvorrr 6y ago
      "No true Scotsman," I'd wager.
    - kangoo1707 6y ago
      No native support for concurrency operators, no real event loop implementation, lack built-in support for non-blocking IO... I do Elixir regularly and Actor Model is not something PHP developers know
      - Spivak 6y ago
        Is this just a long way of saying it doesn’t have “async” because threads are a perfectly fine concurrency primitive that you can build event loops on top of.
        eithed 6y ago
        There is async in PHP
      - macinjosh 6y ago
        > I do Elixir regularly and Actor Model is not something PHP developers know /me clutches pearls What a travesty! I wish, I, a lowly, stupid PHP developer was smart enough to know about the Actor model! /s
castis 6y ago
i think the whole point is that some of those things are not 100% necessary to build great stuff.
tzs 6y ago
> There is no way to easily share memory between processes What about https://www.php.net/manual/en/ref.shmop.php https://www.php.net/manual/en/ref.shmop.php ?
- mywittyname 6y ago
  Yeah, that comment stuck out to me as I've used shared memory segments in PHP before and these functions work just fine.
- merb 6y ago
  not atomic
karatestomp 6y ago
> - 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. You want this in any scripting language if you don’t want memory use and cycles to balloon out of control for simple tasks. Most any scripting language looking for performance is going “how can I GTFO of myself and into C (or assembly, or maybe these days Rust I guess, in some circles) as fast as possible”.
- ferzul 6y ago
  i think it's where the glue goes. do you implement an algorithm/write a generic library in c and then glue it to your high level language in your high level language, or do you write a plugin for your high level language in c? in both cases you need to understand pointers and function pointers and the difference between your integer type and a c int, but in one case you're at home while you do it. in one case, you could plug in to any existing c library without writing additional c, so if the problem is already solved you just use the ffi and you're done. in the other case, your problem is just beginning
ivanhoe 6y ago
> The reason for this is because PHP doesn't support many things that are expected in any other language. And the reason for this is that those parts are handled by web servers and php doesn't need to handle them. Isolation decision that simplifies things significantly infrastructure wise and that allowed for shared hosting to exist - which in turn brought the costs down and made web as popular and massive as it is today. BTW, this architecture is not that different from what node and others are doing. Instead of having a language/framework that acts as a web server (but too simple, so you still need nginx in front), and then you need a queue service to delegate the jobs, you have a web server that delegates the jobs (requests) to isolated php processes. Model is the same and that's the model that's used everywhere today, just that the moving parts are partitioned a bit differently in different languages. Of course, it's not a perfect solution to every problem, but works very good for any not-real-time web site/app and in the end RoR, Django, Symfony, etc. they all work in a very similar way (minus the syntactical nuances). For a massive traffic or language level high parallelism just use something else, no one argues against that.
winrid 6y ago
Simple blocking IO and no real multithreading are features of PHP. It's all about simplicity. In a web app you "multithread" using the web server...

norswap 6y ago

Something being written in C does not mean "understanding or contributing is close to impossible". That's as much of a boogeyman as I've ever seen.

lostcolony 6y ago
It is when discussing the merits of a given language, and the assumption is "a person knows the language under discussion". I.e., for the criticism to not apply in this context, a solid PHP developer...has to also be a solid C developer. Given the context is "using PHP", the former is likely, the latter, not so likely. Exactly how likely I don't know (I don't use PHP, so don't really have an opinion anywaay), but most discussions I've seen around PHP don't also presume the adoption of C.

alphadevx 6y ago

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.

ainiriand 6y ago

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

kangoo1707 6y ago
still, no proper multithreading, in comparison with Java, C#, Elixir...
- ainiriand 6y ago
  Define proper please.
  - Piskvorrr 6y ago
    "No true Scotsman," I'd wager.
  - kangoo1707 6y ago
    No native support for concurrency operators, no real event loop implementation, lack built-in support for non-blocking IO... I do Elixir regularly and Actor Model is not something PHP developers know
    - Spivak 6y ago
      Is this just a long way of saying it doesn’t have “async” because threads are a perfectly fine concurrency primitive that you can build event loops on top of.
      - eithed 6y ago
        There is async in PHP
    - macinjosh 6y ago
      > I do Elixir regularly and Actor Model is not something PHP developers know /me clutches pearls What a travesty! I wish, I, a lowly, stupid PHP developer was smart enough to know about the Actor model! /s

castis 6y ago

i think the whole point is that some of those things are not 100% necessary to build great stuff.

tzs 6y ago

> There is no way to easily share memory between processes What about https://www.php.net/manual/en/ref.shmop.php https://www.php.net/manual/en/ref.shmop.php ?

mywittyname 6y ago
Yeah, that comment stuck out to me as I've used shared memory segments in PHP before and these functions work just fine.
merb 6y ago
not atomic

karatestomp 6y ago

> - 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. You want this in any scripting language if you don’t want memory use and cycles to balloon out of control for simple tasks. Most any scripting language looking for performance is going “how can I GTFO of myself and into C (or assembly, or maybe these days Rust I guess, in some circles) as fast as possible”.

ferzul 6y ago
i think it's where the glue goes. do you implement an algorithm/write a generic library in c and then glue it to your high level language in your high level language, or do you write a plugin for your high level language in c? in both cases you need to understand pointers and function pointers and the difference between your integer type and a c int, but in one case you're at home while you do it. in one case, you could plug in to any existing c library without writing additional c, so if the problem is already solved you just use the ffi and you're done. in the other case, your problem is just beginning

ivanhoe 6y ago

> The reason for this is because PHP doesn't support many things that are expected in any other language. And the reason for this is that those parts are handled by web servers and php doesn't need to handle them. Isolation decision that simplifies things significantly infrastructure wise and that allowed for shared hosting to exist - which in turn brought the costs down and made web as popular and massive as it is today. BTW, this architecture is not that different from what node and others are doing. Instead of having a language/framework that acts as a web server (but too simple, so you still need nginx in front), and then you need a queue service to delegate the jobs, you have a web server that delegates the jobs (requests) to isolated php processes. Model is the same and that's the model that's used everywhere today, just that the moving parts are partitioned a bit differently in different languages. Of course, it's not a perfect solution to every problem, but works very good for any not-real-time web site/app and in the end RoR, Django, Symfony, etc. they all work in a very similar way (minus the syntactical nuances). For a massive traffic or language level high parallelism just use something else, no one argues against that.

winrid 6y ago

Simple blocking IO and no real multithreading are features of PHP. It's all about simplicity. In a web app you "multithread" using the web server...