[jhgb]

So you switched from a language X not designed to do Q to a language Y designed to do Q, presumably because language Y didn't exist when you started doing Q. I imagine that happens all the time, but seldom is it a fault of X. But what I find puzzling is why PHP, of all things, was your choice for these kinds of problems before Go appeared.

[edoceo]

Isn't Go like 10 years old now?

[jhgb]

More like thirteen. Apparently I misread the comment I was responding to as "for two years some time ago". Now I'm not sure why someone would have chosen PHP for such a task two years ago.

[m4l3x]

Sorry for unclear phrasing. I meant I used php from 2018-2020. And honestly I don't know why to use php for the task. I started at the company 2018 and the tech stack was given. A good compensation and praising like "PHP has changed and now supports types etc." let me take the opportunity.

My bad, because it took me a lot of time. I needed to do benchmarks were actually PHP turned out to have comparable performance in the scenario under test (concurrent consuming of message Queues and heavily write operations to databases), however it took more than 4 times the effort to get there with php.

In the end I resigned and switched to a new opportunity doing golang solving similar issues.

My point is, that there are folks out there (ab)using PHP for all and everything. And finally php has made a lot of improvements but it is just catching up with other languages. There are still a lot of libraries, that still use older versions and probably never will get updated.

[jhgb]

The problem with PHP in this case has nothing to do with types. So their reasoning was wrong from the very beginning. I suspect that no amount of "catching up" will help here, just like no amount of development will turn future axes into screwdrivers. They'll still work like perfectly good axes, though. Just like PHP will still be able to handle HTTP requests perfectly well.