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

21–30 of 53 posts

Re: PHP 8.6 Closure Optimizations

#21

Post by Meekro »

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…

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 hardest-to-understand things I've ever seen: in order to really grasp the async/await model, you have to know the whole story of callback hell and how modern Javascript papers over it while carefully preserving backwards compatibility.

Re: PHP 8.6 Closure Optimizations

#22

Post by sidkshatriya »

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'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 parent comment said:

> but if you're building microservices where parallelization is handled by an external orchestrator, then you can design around that pretty effectively.

Re: PHP 8.6 Closure Optimizations

#23

Post by mschuster91 »

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's true that the lack of multithreading in PHP has been a persistent pain.

That's... not necessarily a bad thing to lack. Entire classes of bugs that are common in Java, C/C++, .NET and other true multi-threaded environments simply cannot exist in the PHP world at all.

Re: PHP 8.6 Closure Optimizations

#24

Post by chuckadams »

runjake wrote: post #14
Tadpole9181 wrote: post #13

Earlier quoted context omitted.

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…

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

Re: PHP 8.6 Closure Optimizations

#25

Post by tail_exchange »

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.

For greenfield projects, I agree. It gets the job done, but PHP would never be my choice for a new project. Bun seems like a much better choice in pretty much every criteria.

Re: PHP 8.6 Closure Optimizations

#26

Post by phplovesong »

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…

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

Re: PHP 8.6 Closure Optimizations

#27

Post by phplovesong »

pluc wrote: post #8
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.

Because PHP was designed for this and JS evolved for it. There are still JS quirks that should be avoided.

PHP was not designed

Re: PHP 8.6 Closure Optimizations

#28

Post by troupo »

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.

> because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request.

Where "application" is basically a single page with less code than a typical React page. Even 20 years ago you'd run into DB struggling to give you data fast enough before you hit any issues with the "re-running the entire app".

And you have to screw your database really badly to see any issues early. Hell, phpBB was horrendously bad, running dozens of heavy DB queries on each page, and was still powering some of the internet's busiest forums.

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

Yes. It is an enormous advantage: it's fire and forget. You don't need to "SSR" your app (getting all data and state), ship it to the client with a bundle, then "re-hydrate" it (once again pulling data and state from the server) etc.

Re: PHP 8.6 Closure Optimizations

#29

Post by toast0 »

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.

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

Sure, in PHP, the reality is that after your request is processed, all the state is garbage and is thrown out. But once you embrace that reality and stop trying to make sculpture from garbage, you can make some pretty damn fast pages that get straight to the point. Of course, a lot of people look at my fast PHP and say that it too is garbage, but at least it's fast garbage :P

Post reply on HN