←back to thread

116 points doekenorg | 2 comments | | HN request time: 0s | source
Show context
philo23 ◴[] No.44499201[source]
Personally I've never come across any problem in PHP that I feel like Fibers would help me solve.

Having Fibers in PHP is a nice addition but it definitely feels more like plumbing for other PHP extensions/frameworks to use, rather than something the average dev would use themselves directly day to day.

replies(1): >>44499466 #
jerf ◴[] No.44499466[source]
Of course you haven't come across any such problem in PHP, because up until this point, if you had, you would have had to switch to another language to solve the problem that required the feature PHP didn't have.

There's an evaporative cooling effect on languages that don't have certain features where all the people who need those features leave after some number of years of not having them, leaving behind only the people who don't need them. There's a survivorship bias as a result.

I worked with dynamic scripting languages primarily for the first 15 years of my career but the definitive split for me was precisely when I had a problem they couldn't solve because they couldn't handle tens of thousands of simultaneous connections in any reasonable way.

This reply applies to all the commenters posting "but I've never needed this".

That doesn't mean PHP was useless without this feature, as it observably has solved a lot of problems. It just means that you shouldn't draw out too many conclusions from "I've never needed it", because you're still using it precisely because you're working in a space that doesn't need it, and your community is not constantly complaining about it because the people who would be complaining are no longer in your community. It means if you do develop a need for it in the future you won't have to leave PHP.

As a result this is a bad metric to measure the utility of a feature with.

On the flip side, it is valid to say "we've come this far without it and maybe we should be focusing on what we can do and continuing to invest in making that better rather than chasing the things we can't", especially since features like adding true threading add a lot of constraints to an implementation and make everything else you ever do in that implementation more expensive. Personally I am of the opinion that all of the dynamic scripting languages really need to just settle down, accept that they are what they are, and stop adding feature after feature after feature to 25-30 year-old languages.

replies(1): >>44502523 #
philo23 ◴[] No.44502523[source]
Genuine question, what kind of problems would using fibers help with?

To be clear, my point wasn’t that I think fibers are useless or that people shouldn’t use them. I think it was a great addition.

Just that they wouldn’t be directly useful to the average PHP dev, until they’re being used by frameworks/libraries/extensions, say for example: a HTTP library that can fire off multiple requests asynchronously.

replies(1): >>44503616 #
1. jerf ◴[] No.44503616{3}[source]
One of my standard answers here is a chat server. You've got thousands upon thousands of connections to it, which are all live, and they're cross-talking with each other in arbitrary ways. The easiest way to write that is to assign a fiber per connection. You shouldn't do that in PHP today.

"Just that they wouldn’t be directly useful to the average PHP dev,"

But you're restating my point, whether you realize it or not. They're not useful to the "average PHP dev" because if the "average PHP dev" needed them, they would cease to be a PHP dev, just as I ceased to be a Perl dev when I needed something it couldn't do for similar reasons. All the use cases that PHP could have with fibers have evaporatively-cooled out of the community because PHP couldn't do them, leaving behind precisely that set of people who don't have problems that could be solved with fibers.

replies(1): >>44561796 #
2. g8oz ◴[] No.44561796[source]
>>The easiest way to write that is to assign a fiber per connection. You shouldn't do that in PHP today.

Can I ask why? Is the implementation not performant enough?