Live data from Hacker News

PHP 8

php.net

71–80 of 273 posts

Re: PHP 8

#71
post #39

Does PHP still has that weird flow where each request is its own process? afair PHP never had an http server baked in, I remember nginx with php etc ...

That is not a problem with PHP itself, but the way that Apache/Nginx operates PHP. However, if you want to go full PHP, there is this extension that is pretty amazing (has a built-in server on it and more): https://www.swoole.co.uk/

ps: https://github.com/swoole/swoole-src/issues/1401 some performances benchmark (they compare it even with golang)

Re: PHP 8

#72

Earlier quoted context omitted.

'foobar' is coerced into a number, which fails for the obvious reason. So it becomes 0, which means the expression is "0 == 0". Terrible, terrible, behaviour but there are lots of similar examples in PHP because it evolved over time rather than being designed as-is. Some of these things are being fixed over time, like this very example, others can't/won't be.

In the absence of strict type checking it would be terrible, but == performs a loose comparison, and "foobar" cannot cast to any other number than 0. Perl will go about it the exact same way. Contrast this against strict comparison, "0" === 0 , which will evaluate as false.

>Perl will go about it the exact same way.

No, Perl is completely different and IMO it's the only mainstream dynamically typed language that has sane comparison operators.

Perl has two sets of operators, numeric (==, +, *, , etc.) and stringwise (eq, ., lt, gt, cmp etc.). You can think of them as explicit (but concise) casts. For example, Perl's $foo eq $bar is roughly equivalent to Python's str(foo) == str(bar).

It is true that "foobar" == 0 returns true in Perl but, as I showed above, it does that for a completely different reason.

Re: PHP 8

#73
post #59

Earlier quoted context omitted.

That's a local effect that can be avoided once you know the sematincs of the language. The issue with abused metaprogramming and monkey patching is that it results in global effects that are hard to track. I would prefer to review a messy 50kloc php project over a messy 50kloc ruby project.

I was citing it as a good thing versus PHP's (and Perl's) "foo" == 0;// true behavior. I believe that still to be the right thing despite other issues Ruby has.

Then I agree of course!

Re: PHP 8

#74
post #4

Apparently some of the deprecations will make this the most backward compatibility breaking version jump of PHP since V4 to V5. (Read a german interview here: https://www.heise.de/news/PHP-8-im-Experten-Check-Der-erwart... ) There's a long report on Wordpress and PHP 8 and it's not pretty: https://developer.yoast.com/blog/the-2020-wordpress-and-php-...

I never want to get within a mile of a wordpress website after reading this.

Re: PHP 8

#75
post #19

Earlier quoted context omitted.

Reading the list of things that worry them makes it clear that it's not so much php is breaking bc than it is wordpress lack of cleaning and linting for so long catching up to them. I mean seriously the first thing they list as a worry is that arithmetic operators will now throw an error when one (and only one) of their operand is an array or resource (eg array + array support remains, it's really int + array or stri…

> This is literally a case that makes no sense in the code ever, Speaking as someone that hates PHP but still appreciates that it has its uses: You’re speaking from one perspective. There are others. That operation is perfectly valid and well-defined in Matlab where it increments all members of the matrix/vector by the scalar.

Did it php use to do that? Otherwise your point is invalid.

Re: PHP 8

#76
I don't really like PHP, but it pays my bills. There are some big improvements in this release. Named arguments and actual attributes (instead of special tags in comments) are really nice.

Re: PHP 8

#78
post #68
post #39

Does PHP still has that weird flow where each request is its own process? afair PHP never had an http server baked in, I remember nginx with php etc ...

Yes, each request is handled by its own process. This might sound weird if you're used to other languages, but it's how every language used to work in the good ol' CGI days. PHP doesn't break backward compatibility easily, and I don't think it will ever break this one. Besides, once you get the hang of it, PHP's execution model is highly intuitive and beginner-friendly. You simply don't have to worry about a whole cl…

The PHP doc advices you that the built-in server from PHP should be used only for development: https://www.php.net/manual/en/features.commandline.webserver.... But PHP-FPM is the most used nowadays, for sure.

Re: PHP 8

#79

I wonder what makes the Symfony Demo App not being faster with the JIT compiler (as shown on https://www.php.net/releases/8.0/en.php and https://susi.dev/php8-benchmark-jit-symfony ). Maybe because Symfony already caches things very efficiently/cleverly with OPCache?

Mostly because only cpu-intensive code greatly benefits from JIT. Serving a blog (like the demo) is not much cpu-intensive.

Re: PHP 8

#80

Php was my first language I learned 15 years ago. On that way I really started to hate it because of all it's quirks. Many of those have been fixed and nowadays I really enjoy it again and it's my goto language for any web project. It really hits a pragmatic sweetspot. It's really easy to deploy and frameworks like symfony give you all the power like rails but without the magic.

I must be very picky, because to this day I still don't like it at all. It sucks less than it used to maybe, but if I compare it to other languages, I still would rather use anything else.

I think you have to do webdev to really enjoy it, I never write PHP unless it's something with laravel.
Post reply on HN