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

41–50 of 53 posts

Re: PHP 8.6 Closure Optimizations

#41

Post by archerx »

Tadpole9181 wrote: post #13
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…

As someone who prefers PHP in general and find the TC39 committee has kneecapped the JS language in the past few years... > PHP has a vastly simpler toolchain Firmly disagree. 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 and then reconfiguring a slurry of bad defaults. If you don't avoid the footgun of "traditional" deployments, y…

I’ve been using PHP for over a decade and have never used FPM.

“Using a single language for both frontend and backend with (largely) the same availability of tooling and the ability to share code”

Is a negative I went backend world and front end world to be different because they do very very different things.

“But more than that... it's just less used? The PHP ecosystem is noticeably smaller and has way less happening.”

That’s not true, PHP is less resume driven development and actually about productivity. I’m really happy narcissist hate PHP and don’t burden it with their garbage and slopworks.

Re: PHP 8.6 Closure Optimizations

#42

Post by sellmesoap »

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…

I think frankenphp checks a lot of boxes here, go to handle the threads with php built in https://frankenphp.dev/

Re: PHP 8.6 Closure Optimizations

#43

Post by jamesfinlayson »

hparadiz wrote: post #15
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.

I have a lot more confidence in composer deps versus npm deps and it's not even close.

Huge agree. I think I've nuked vendor/ a handful of times in 8 years of doing PHP while I've lost track of the number of times I've deleted node_modules/ this year alone.

Re: PHP 8.6 Closure Optimizations

#44

Post by user3939382 »

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…

It’s a “terrible” language? That’s news to me. What’s “terrible” about it?

> `new MyClass() === new MyClass()`

Does that look like the code you’re writing for some reason? Because I’ve seen 100k loc enterprise PHP apps that not once ran into that as an issue. The closest would be entities in an ORM for which there were other features for this anyway.

Re: PHP 8.6 Closure Optimizations

#45

Post by 9dev »

dgb23 wrote: post #16
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…

PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request. Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

That ceased to be true a while ago since the ecosystem gravitated towards FrankenPHP, a stateful application server written in Go as a Caddy module. The performance is amazing, the Go Bridge allows easy extension, and it’s rock solid.

Re: PHP 8.6 Closure Optimizations

#46

Post by martinald »

Gormo wrote: post #36
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…

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

Yeah, though AFIAK these event loops still suffer from blocking on (eg) complex json parsing or anything CPU driven (where real multithreading shines).

But regardless I agree, I'm just saying that these kind of patterns _are_ needed in any moderately complex system, and taking the view that "it's great not to even have it" in the core framework is really strange to me. Esp given every machine I have these days has >10 CPU threads and it won't be long before 100+ is normal.

Re: PHP 8.6 Closure Optimizations

#47

Post by Gormo »

martinald wrote: post #46
Gormo wrote: post #36

Earlier quoted context omitted.

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

Yeah, though AFIAK these event loops still suffer from blocking on (eg) complex json parsing or anything CPU driven (where real multithreading shines). But regardless I agree, I'm just saying that these kind of patterns _are_ needed in any moderately complex system, and taking the view that "it's great not to even have it" in the core framework is really strange to me. Esp given every machine I have these days has >1…

> Yeah, though AFIAK these event loops still suffer from blocking on (eg) complex json parsing or anything CPU driven (where real multithreading shines).

This is only a problem if the JSON parsing is being done inside the event loop itself. The idea here is that you'd have a separate JSON-parser service that the code in the event loop passes the JSON into, then continues executing the other operations in the loop while it awaits the response from the JSON parser.

Just translate anything you'd spawn a parallel thread for into something you'd pass to a separate endpoint -- that's what I was referring to when I said that the poor multithreading can be easily worked around if you're achieving parallelization by orchestration of microservices.

Re: PHP 8.6 Closure Optimizations

#48

Post by moebrowne »

Gormo wrote: post #38
chuckadams wrote: post #24

Earlier quoted context omitted.

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.

By default the dev server is single threaded, but since PHP 7.4 you can add more with an env: `PHP_CLI_SERVER_WORKERS`

Re: PHP 8.6 Closure Optimizations

#49

Post by edmondx »

Meekro wrote: post #21
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…

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 seems like you’re talking about something similar: https://true-async.github.io/en/docs/components/thread-pool....

I’ve also wanted parallelism in PHP for a long time. Especially the kind of parallelism that works together with concurrent I/O. That’s when it becomes truly useful, not just a toy.

Asynchrony will always be a complex tool because of the number of states involved. That’s true. But if it’s made convenient and used properly, it becomes enjoyable to work with.

Re: PHP 8.6 Closure Optimizations

#50

Post by edmondx »

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…

> 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?

Post reply on HN