Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring Coroutines in PHP

doeken.org

Post reply on HN
Print view View original

11–20 of 68 posts

Re: Exploring Coroutines in PHP

#11

Post by zelphirkalt »

Amakanski wrote: post #3

>> This would require a yield to syntax, which doesn't exist. There is however the 'yield from' statement.

This means, that most likely the keyword will not be "yield". PHP is not known for keeping a low number of keywords. Rather they introduce new ones, to tack on things to the language, like one can see in the implementation of anonymous functions, where one needs to use "use" explicitly, instead of the language having the semantics that most other languages have for lambdas. Which immediately turns in to a source for nullability errors.

Re: Exploring Coroutines in PHP

#12

Post by ckbkr10 »

zelphirkalt wrote: post #10
cardanome wrote: post #6

Earlier quoted context omitted.

I work daily with PHP and honestly nearly all my code I write is synchronous. The shared-nothing architecture of PHP makes that really a non-issue for me. Requests never share any state with each other. Something like RabbitMQ can handle communication between systems.

That's in no way lightweight though, and most languages can easily do the same. Just launch multiple instances/VMs/processes. That's having multiple separate OS processes, each having everything that is needed to run PHP, and having no way to communicate with each other, other than what you implement. No channels, no task distribution, no queue on which to sync and take tasks from, no signaling of all processes being…

PHP is not about lightweight, it's about rapid development. A lot of implementations in PHP are dead simple and can be debugged even by beginners.

You generally do not implement efficient systems in php, they are easy to debug, fast to code and quick to fix though.

Re: Exploring Coroutines in PHP

#13

Post by supriyo-biswas »

zelphirkalt wrote: post #8

I think neither does PHP have the ecosystem for it, nor does it have the language primitives or standard library for it. Much cleaner languages than PHP already have enough issues getting concurrency things like fibers right. I don't see this ending in any implementation, that doesn't have surprising dysfunctional parts in it. Especially not, when again and again people behind PHP chose the easy way out for adding la…

> like they did with lambdas, that don't capture their environment

https://www.php.net/manual/en/functions.arrow.php

Re: Exploring Coroutines in PHP

#14

Post by conradfr »

zelphirkalt wrote: post #8

I think neither does PHP have the ecosystem for it, nor does it have the language primitives or standard library for it. Much cleaner languages than PHP already have enough issues getting concurrency things like fibers right. I don't see this ending in any implementation, that doesn't have surprising dysfunctional parts in it. Especially not, when again and again people behind PHP chose the easy way out for adding la…

The standard lib thing is overblown. What exactly is bothering you?

And PHP has deprecated a lot of things along the way.

Re: Exploring Coroutines in PHP

#15

Post by Cyykratahk »

Amakanski wrote: post #3

>> This would require a yield to syntax, which doesn't exist. There is however the 'yield from' statement.

I'd use `yield from` more if I didn't have to re-index arrays before yielding from them:

    function numbers() {
      yield from [1,2,3];
      yield from [4,5,6];
    };
    
    foreach (numbers() as $k => $v) { echo "$k => $v\n"; }
    0 => 1
    1 => 2
    2 => 3
    0 => 4
    1 => 5
    2 => 6

Re: Exploring Coroutines in PHP

#16

Post by djxfade »

zelphirkalt wrote: post #11
Amakanski wrote: post #3

>> This would require a yield to syntax, which doesn't exist. There is however the 'yield from' statement.

This means, that most likely the keyword will not be "yield". PHP is not known for keeping a low number of keywords. Rather they introduce new ones, to tack on things to the language, like one can see in the implementation of anonymous functions, where one needs to use "use" explicitly, instead of the language having the semantics that most other languages have for lambdas. Which immediately turns in to a source for…

That's not totally correct. PHP has a "short function" syntax for that specific use case, it automatically captures data without the 'use' statement.

    $a = 5;
    $b = fn ($c) => $a * $b;
    print($b(2)); // 10
    print($b(4)); // 20

Re: Exploring Coroutines in PHP

#17

Post by Cthulhu_ »

pachico wrote: post #4

I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.

It's better to build your app in e.g. PHP, prove its worth, then identify the bottlenecks, THEN determine if you need multi-threading. And if so, determine if PHP would be the best language for it or if you'd be better off going for a different language - one with parallelism / multithreading built into its core architecture.

The first logical step after PHP is NodeJS, which has the fast iteration cycles of PHP without the low-level memory management or the enterprisey application server headaches of other languages, AND it has the advantages of a persistent service without needing to worry too much about parallelism because it's still single process.

But if you still need more performance you have a few options. But if you're at that point, you're already lucky. Most people wish they needed the performance or throughput of a language/environment like Go.

Re: Exploring Coroutines in PHP

#18

Post by Klathmon »

zelphirkalt wrote: post #10
cardanome wrote: post #6

Earlier quoted context omitted.

I work daily with PHP and honestly nearly all my code I write is synchronous. The shared-nothing architecture of PHP makes that really a non-issue for me. Requests never share any state with each other. Something like RabbitMQ can handle communication between systems.

That's in no way lightweight though, and most languages can easily do the same. Just launch multiple instances/VMs/processes. That's having multiple separate OS processes, each having everything that is needed to run PHP, and having no way to communicate with each other, other than what you implement. No channels, no task distribution, no queue on which to sync and take tasks from, no signaling of all processes being…

PHP's approach is simple though, and in my experience that simplicity pays off when you do start scaling the systems.

In other systems once you get beyond a single machine you need that external communication mechanism anyway, and now you have multiple classes of comms which introduces bugs and complexity and performance cliffs.

In PHP you just throw another server at it, it'll act the same as if you just added another process. Nice linear scaling and simple to understand architectures.

Man I miss working in PHP

Re: Exploring Coroutines in PHP

#19

Post by philo23 »

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.

Re: Exploring Coroutines in PHP

#20

Post by zelphirkalt »

supriyo-biswas wrote: post #13
zelphirkalt wrote: post #8

I think neither does PHP have the ecosystem for it, nor does it have the language primitives or standard library for it. Much cleaner languages than PHP already have enough issues getting concurrency things like fibers right. I don't see this ending in any implementation, that doesn't have surprising dysfunctional parts in it. Especially not, when again and again people behind PHP chose the easy way out for adding la…

> like they did with lambdas, that don't capture their environment https://www.php.net/manual/en/functions.arrow.php

Yes this exists, but again introduces a new thing into PHP, rather than using an existing thing. Instead of using existing function syntax and leaving away the name, now one has 2 more things: The "fn" (why can this not be "function" which already exists?) and in combination with "=>". So it is similar to "function ... use ..." which also has the need to introduce a new thing, the "use", instead of simply capturing its environment.

The point is, that the designers of PHP decide again and again to add another wart, rather than designing the language in an extensible way. Here a little extra, there a little extra, here a new keyword, there a new thingy. Compare that with other languages. Even JavaScript has managed to have simply the same syntax for functions and anonymous functions. Although it did also introduce an arrow syntax. However it's arrow syntax is not really needed, even though shorter, in contrast to PHP, where you need it, unless you want to list all the parts of the environment you need in the anonymous function. At least in JS they didn't introduce a new extra thing like "fn".

I don't think the design of PHP is done with good oversight. It is done with the approach of tacking things onto what exists, in the easiest way they are able to do, without any goal of keeping the language concepts and keywords minimal. Designing something like "fn" or "use" is a hack to make implementation easier, because they are previously unused keywords, that will then make it easier to adapt the parser for the language, but these decisions are offloading mental load to the user, which ultimately is a bad design.

Post reply on HN