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

PHP 8.6 Closure Optimizations

wiki.php.net

Post reply on HN
Print view View original

31–40 of 53 posts

Re: PHP 8.6 Closure Optimizations

#31

Post by tialaramex »

ragnese wrote: post #20
eurleif wrote: post #9

Earlier quoted context omitted.

The part that would violate guarantees in JavaScript is not function objects being kept alive longer, but function objects which should be distinct not being so. function foo() { return function() { }; } console.log(foo() === foo()); // This must log `false` in a compliant implementation

This is also a problem, IMO, in having this optimization in PHP. Anonymous functions are instances of a Closure class, which means that the `===` operator should return false for `foo() === foo()` just like it would for `new MyClass() === new MyClass()`. But, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP a…

I never understood why people think somehow PHP is fine now, and I've had that opinion expressed several times on HN. The best I can make out is that people's expectations are so dismal now that they're like "Well new versions fixed 2 of the 5 worst problems I noticed, so that's good right?"

Re: PHP 8.6 Closure Optimizations

#32

Post by martinald »

sidkshatriya wrote: post #22
Meekro wrote: post #21

Earlier quoted context omitted.

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…

> 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 par…

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.

Re: PHP 8.6 Closure Optimizations

#33

Post by cardanome »

tialaramex wrote: post #31
ragnese wrote: post #20

Earlier quoted context omitted.

This is also a problem, IMO, in having this optimization in PHP. Anonymous functions are instances of a Closure class, which means that the `===` operator should return false for `foo() === foo()` just like it would for `new MyClass() === new MyClass()`. But, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP a…

I never understood why people think somehow PHP is fine now, and I've had that opinion expressed several times on HN. The best I can make out is that people's expectations are so dismal now that they're like "Well new versions fixed 2 of the 5 worst problems I noticed, so that's good right?"

Because PHP is a amazing backed language for making CRUD apps. Always has been.

It has great web frameworks, a good gradual typing story and is the easiest language to deploy.

You can start with simple shared hosting, copy your files into the server and you are done. No docker, nothing.

Sure it has warts but so have all mainstream programming languages. I find it more pleasant than TypeScript which suffers from long compile times and a crazy complex type system.

The only downside is that PHP as a job means lots of legacy code. It a solid career but you will rarely if ever have interesting programming projects.

Re: PHP 8.6 Closure Optimizations

#34

Post by theodorejb »

martinald wrote: post #32
sidkshatriya wrote: post #22

Earlier quoted context omitted.

> 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 par…

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…

This can be done with curl_multi_exec(), or with $client->getAsync() in Guzzle.

https://www.php.net/manual/en/function.curl-multi-exec.php

https://docs.guzzlephp.org/en/stable/quickstart.html#concurr...

Re: PHP 8.6 Closure Optimizations

#35

Post by bakkoting »

Gormo wrote: post #10
typia wrote: post #7

Whenever looking at PHP contents, as a lover who has used since 1998, cannot find the reason why not to use JS instead.

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead. PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to…

> type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to still have interpreted code at the end)

All major server-side JS runtimes are capable of executing TypeScript without transpilation these days. Complex build processes are only really a thing for client-side JS. The normal state of affairs these days is to run server-side code with no build step whatsoever.

Re: PHP 8.6 Closure Optimizations

#36

Post by Gormo »

martinald wrote: post #32
sidkshatriya wrote: post #22

Earlier quoted context omitted.

> 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 par…

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…

> What if you need to call multiple external APIs at once with complex json?

A few years ago, I had a PHP project that had grown by accretion from taking a single complex input and triggering 2-3 external endpoints to eventually making calls to about 15 sequentially. Processing a single submission went from taking 5-10 seconds to over five minutes.

This was readily solved by moving to ReactPHP (https://reactphp.org/), which implements async via event loops. I was able to reduce the 15 sequential external API calls to four sequential loops (which was the minimum number due to path dependencies in the sequence of operations). That reduced the five minutes back to an average of 20-30 seconds for the complete process.

It wasn't using true multithreading, but in a situation where most of the time was just waiting for responses from remote servers, an event loop solution is usually more than sufficient.

Re: PHP 8.6 Closure Optimizations

#37

Post by Gormo »

theodorejb wrote: post #34
martinald wrote: post #32

Earlier quoted context omitted.

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…

This can be done with curl_multi_exec(), or with $client->getAsync() in Guzzle. https://www.php.net/manual/en/function.curl-multi-exec.php https://docs.guzzlephp.org/en/stable/quickstart.html#concurr...

ReactPHP is another good option.

Re: PHP 8.6 Closure Optimizations

#38

Post by Gormo »

chuckadams wrote: post #24
runjake wrote: post #14

Earlier quoted context omitted.

> You can install Node and have a basic server running in a few seconds. PHP requires installing and setting up a server tied into FPM... Without mentioning more, the PHP equivalent to your Node example is `php -S`.

Or FrankenPHP, or hell, there's still even good old Apache. Or avoid the SAPI interface entirely with servers in PHP like Workerman, AMPHP, or Swoole. FPM is entirely too fussy for me to bother with: its error handling is atrocious (restarting in an infinite loop with no backoff is common), and no one really knows how to tune it.

Those are great solutions for production deployment, but to the previous commenter's point, for iterating on your local machine during development work, nothing beats just running `php -S`.

Launch the interpreter's built-in dev server in your project directory, load up localhost in your browser, work on your code, and testing incremental changes locally is just a matter of hitting F5.

Re: PHP 8.6 Closure Optimizations

#39

Post by Gormo »

bakkoting wrote: post #35
Gormo wrote: post #10

Earlier quoted context omitted.

Conversely, whenever I see people talking about server-side JS, I can't find any reason why I wouldn't use PHP instead. PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to…

> type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to still have interpreted code at the end) All major server-side JS runtimes are capable of executing TypeScript without transpilation these days. Complex build processes are only really a thing for client-side JS. The normal state of affairs these days is to run server-side code with no build…

That's true to some extent, but working with many modern frameworks often still requires a build step. Next.js in particular has quite a heavy toolchain.

Re: PHP 8.6 Closure Optimizations

#40

Post by hajile »

phplovesong wrote: post #26
ragnese wrote: post #20

Earlier quoted context omitted.

This is also a problem, IMO, in having this optimization in PHP. Anonymous functions are instances of a Closure class, which means that the `===` operator should return false for `foo() === foo()` just like it would for `new MyClass() === new MyClass()`. But, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP a…

Its bad indeed. Its unfixable at this point. We just get bolton features.

We could do something like `#function() {}` or `#() => {}` which makes a function static.
Post reply on HN