PHP 8.2.0 RC1 available for testing | Hacker News Reader

PHP 8.2.0 RC1 available for testing

php.net

85 pointsvedranm33 comments

It's really good seeing PHP keep to a solid and reliable release schedule. With the creation of the PHP Foundation to ensure that there are actually developers getting paid to work on PHP I think the future for the PHP core is looking rather bright.

Been using it so far using a PPA with my own unreleased Python dialect that compiles to PHP. Gonna be a solid release.

Amazing to see so much evolution for PHP- autoloading and automatic file-based routing are such killer features for rapid development.

Fibers are going to be a gamechanger for performance once libraries start adopting it.

Fibers were released in 8.1 but are there improvements in 8.2?

I'm curious to see how useful it is until a lot of core libraries (curl, redis, mysqlnd, etc) can be called non-blocking and/or trigger a fiber yield during a block? My understanding is swoole does a whole lot of work to enable hooking into those to allow coroutines, which won't implicitly exist with fibers?

IMO, unless I am mistaken, using a continually running PHP process like Swoole removes advantages you get with vanilla PHP: fully isolated requests, file based routing, etc.

This is why fibers are so big. It'll bring performance without the downsides.

Coroutines have been available via many packages for a while; (Open)Swoole and Amp come to mind, but there are probably others. Laravel has supported using (Open)Swoole via Octane for over a year. Why would having coroutines as fibers in the core be a gamechanger?

See: https://news.ycombinator.com/item?id=32726419

Performance without downsides.

> Why would having coroutines as fibers in the core be a gamechanger?

Plenty of technical reasons but for me, the biggest is unity among libraries/technologies. There been versions of coroutines/fibers around PHP for many years, first time I heard about it was a PHP fork that implemented fibers, don't recall the name but must have been something like 10 years ago...

But the problem has always been that you cannot rely on the community having things like that available.

Having it in the core language, means that more libraries can depend on it, and users are therefore incentives to learn more about it, as they can rely on it sticking around.

Overall, I'm happy it's coming into the core language.

> first time I heard about it was a PHP fork that implemented fibers, don't recall the name

Probably thinking of HHVM/Hack: https://docs.hhvm.com/hack/asynchronous-operations/introduct...

> Having it in the core language, means that more libraries can depend on it, and users are therefore incentives to learn more about it, as they can rely on it sticking around.

Symfony 6.1 and the upcoming Laravel 10 require PHP 8.1+, but I don't see them using fibers yet. We'll have to wait and see.

What's the benefit of compiling a Python-like language to PHP instead of just using PHP?

Existing familiarity with a python-like language? Lack of motivation to learn the intricacies of PHP? (valid reasons and I'm not trying to sound sarcastic here).

Avoiding PHP syntax alone is a big plus to me.

It's the $varname syntax right? I get angry about it too.

; is optional

{ and } is optional

$ is optional

new is optional

attribute access -> is now .

associative array (dict / map) => is now :

I think the $ syntax is the best decision they ever made. It's probably why they can keep modernizing the language so successfully.

PHP is really cool, the reason I created an account here is cos someone was bashing PHP, so I had to troll him.

There is a but though, don't make PHP your last language, broaden your horizon.

Historically up to this point, I don't see anything that would have prevented you from doing most excellent things in this world, if PHP was the last and only programming language you had ever learned or known about.

Has anyone made FFI bindings so we can write kernel modules in PHP yet?

I mean all this push for "Rust in the kernel" is nice and all, but do we really need fancy things like "transitive equality"? They have played us for absolute fools.

Sometimes you just want a language that really puts in the work to find a reason why "0x10" == "16z" should be true, no matter what kind of improbable implicit casts have to be done to get there.

PHP makes the impossible possible, and you've got to keep life interesting or it would be too predictable!

  $ php -r 'var_dump("0x10" == "16z");'
  bool(false)
  
  $ php -r 'var_dump(0x10 == "16z");'
  bool(false)
  
  $ php -r 'var_dump(0x10 == (int)"16z");'
  bool(true)

True! Apologies for the mistake :)

I enjoyed PHP at one point. I wrote frameworks, ORM's, NLP, template engines, etc..

Then I discovered Go which is like a grown-up version of PHP. Really simple to get started, solid standard library (PHP relies a lot on extensions), and fixes all the little things like formatting/styling, testing, error handling, benchmarking, modules, and parallel code execution.

It does all this in much less memory and is much faster.

Go is an excellent replacement for PHP when you start hitting the limits of little Laravel apps.

After reading this article about Go vs Rust, I don't think I can use Go anymore. It's simply not well designed.

[0] https://news.ycombinator.com/item?id=25616593

Oh sure, but getting developers to jump from PHP to Rust is a lot harder. Conversely, it's easier to get PHP developers to jump to Node.js despite all it's issues as well.

I mean, Go is still miles above scripting land. 75% of all the cloud computing projects are in Go and if you deal with micro services you'll find a lot of the tooling and systems are written in Go.

If you're using PHP, then Go or Java is much easier upgrade path than Rust.

I got into programming websites with PHP at a time when everyone was yelling Node for everything, JavaScript frameworks for everything, SPAs for everything.

I absolutely agree they have their place... but I don't have regrets. I'll get into JS Frameworks, Node, and all of that later as it never, ever hurts to broaden experience, but I have no regrets with jumping into PHP first because the productivity level is fantastic when tied to a framework to avoid the footguns. PHP has footguns, some infamous, but so does any framework or language.

A template language that requires manually calling htmlspecialchars on every single value (or else you have an XSS vulnerability) seems like an enormous footgun. In Django this problem was corrected before the 1.0 release.

Is this issue a footgun in Symfony, since you're comparing a framework of one language (Python) with a PHP language by itself?

> ... when tied to a framework to avoid the footguns.

Escaping is typically handled in the framework.

Oops, I missed that part when I read the comment I was replying to. Thanks.

>Django

You need to use a similar PHP framework, with one such framework you don't need to escape html or sql stuff.

Are you talking about outputting unsafe user input? Laravel is the Django of the php world and does that out of the box. You could clean your user input before storing/displaying as best practice suggest.

PHP isn't really used as a template language any more. Most people use a different template language for the views. I've implemented two myself[0][1] but an early one was Smarty[2] and there are many others. I hear Twig is pretty good[3].

[0]: https://github.com/jbboehr/php-handlebars [1]: https://github.com/jbboehr/php-mustache [2]: https://www.smarty.net/ [3]: https://twig.symfony.com/

If you're not using it as a template language though, why use PHP in the first place? Having to use a separate framework puts it on equal footing with every other language.

it just works with no fuss. no compiling. no memory leaks because it dies after every request. the standard library, despite being horrifically inconsistent, has everything you need

Reply on news.ycombinator.com