alt Hacker News> 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.
Replies
I feel like I'm on a different planet when I see this kind of comment.
What if you need to call multiple external APIs at once with complex json? Sure you can call them one after another, but if each take (say) 2s to return (not uncommon IME), then you are in real trouble with only one thread - even if it is just for one "request".
I guess I'm spoilt in .NET with Task.WhenAll which makes it trivial to do this kind of stuff.
> No actually it's a joy to have no multithreading.
To build CPU-bound applications in PHP, you have to install a bunch of packages, rely on Redis, and try to approximate what Python or Go can do in a dozen lines of code. Can that really be enjoyable?