It's true that the lack of multithreading in PHP has been a persistent pain. I love PHP and I've done PHP-centric projects for 20 years, but I end up falling back to Go when it's time to write a background worker that will handle lots of tasks in parallel. I really wish my PHP apps could include native components that process background tasks in parallel.

On the other hand, Javascript's parallelization is one of the hardest-to-understand things I've ever seen: in order to really grasp the async/await model, you have to know the whole story of callback hell and how modern Javascript papers over it while carefully preserving backwards compatibility.

> It's true that the lack of multithreading in PHP has been a persistent pain.

No actually it's a joy to have no multithreading. It keeps the complexity budget lower. You can do multithreading through a custom PHP module if you had a very specific need. Maybe my requirements were too simple but I've never really felt the need. The shared nothing PHP architecture really helps you get away with this.

Anyways as the parent comment said:

> but if you're building microservices where parallelization is handled by an external orchestrator, then you can design around that pretty effectively.

> It's true that the lack of multithreading in PHP has been a persistent pain.

That's... not necessarily a bad thing to lack. Entire classes of bugs that are common in Java, C/C++, .NET and other true multi-threaded environments simply cannot exist in the PHP world at all.