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

PHP 8

php.net

Post reply on HN
Print view View original

251–260 of 273 posts

Re: PHP 8

#251

Post by mmerlin »

chipotle_coyote wrote: post #242
adimitrov wrote: post #185

Earlier quoted context omitted.

> - but I'm only half-joking when I quip that PHP has evolved from its roots as a cargo cult version of Perl into a cargo cult version of Java. It's a joke in so far as it is funny - but it's absolutely correct. When you only look at the language... When looking at the VM, Java has an absolutely world class VM, with great engineering and decades worth of research poured into it. PHP has... no such thing.

I was definitely talking about the syntax. I'm not a huge fan of Java (as I suppose the joke already demonstrated), but I also notice how many places start out with PHP or Ruby or Python and end up moving to, if not Java, a language running on the JVM. So I still appreciate it. :) To give PHP its due, it can be very fast -- although the more you use it "the modern, right way," the slower it seems to get. I can't help…

"by the time every class is instantiated and interface is implemented, ten thousand lines of code have been processed with each request."

Haha so true... the first time I stepped through a running Laravel app line-by-line in debug mode in order to understand it better, I was worried my F11 key was going to wear out ;)

Re: PHP 8

#252

Post by eitland »

marc_io wrote: post #136
muglug wrote: post #128

Earlier quoted context omitted.

> WordPress has always been huge on backward compatibility. Yes, and I think that's ultimately the root of its challenges. A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app. I wrote this two years ago, and WordPress's basic architecture hasn't changed since: https://medium.com/@muglug/improving-wordpress-with-static-a...

> A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app. They are strongly advocating Javascript as the future of WordPress right now, so I'm not sure if they would like it to become a modern looking PHP application.

Interestingly the one other mainstream language that manages to mess up

- equality

- type coercion

- array handling

and more to the same degree as PHP :-)

Re: PHP 8

#253

Post by spdionis »

jontro wrote: post #189
Zancarius wrote: post #126

Earlier quoted context omitted.

> Terrible, terrible, behaviour but there are lots of similar examples in PHP So true. One I ran into recently was comparing hashes that start with '0e' and contain only a numeric component after that prefix. Failure to use the identity operator means that you can have two different hashes returning... equality. PHP apparently thought it a good idea to coerce that into 0 raised to an exponent, which of course always…

Is this fixed in php 8? I did not think this was possible as there is no type coercion and not well documented. [1][2] Noticed "0.2" == "0.20" as another example [1] https://www.php.net/manual/en/language.operators.comparison.... [2] https://www.php.net/manual/en/language.types.type-juggling.p...

It is well documented that strings are converted to integers when comparing with integers.

It is well documented that when converted to integers, strings containing a number at the start will be converted to that number, and drop any string after, e.g. '1eabc' becomes 1.

It's also been a best practice for a looong time (since something like PHP 5.4) to use === to test for equality.

Re: PHP 8

#254

Post by rovr138 »

bavell wrote: post #22
sleavey wrote: post #13

Earlier quoted context omitted.

I see. This change prompts me as something that could break a lot of code running on web servers where the sysadmin updates to PHP8 assuming it will be backwards compatible. I wonder if they did any code searching to see how widely used such expressions are in the wild.

I don't think anyone reading the migration guide [0] is going to assume their app/lib is backwards compatible without some effort. [0] https://www.php.net/manual/en/migration80.php

And anyone that knows the basics about semver

Re: PHP 8

#255

Post by FranOntanaya »

kijin wrote: post #92
zexias wrote: post #78

Earlier quoted context omitted.

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.

I find the built-in web server very useful for running tests. Instead of setting up Apache or nginx on every CI build, you just fire up the built-in web server and point your tests at it.

I use it for small scripted jobs on my own machine that have to go through a proxy, I start the built-in server on the proxy root and point the script to the localhost address.

Re: PHP 8

#256

Post by radlad »

ericbarrett wrote: post #118

Facebook’s backups were written in PHP. Well, the second version was, anyway. (The first version didn’t work so well.) By backups, I mean the central MySQL databases with profile and post information; not media or messages. The “Crown Jewels,” so to speak. It was written by an engineer in a week or so and then handed off to me. I was a storage guy with some programming chops. Fewer chops than I thought. Multiprocess,…

Barracuda Backup was also written in PHP - including code to backup VMware servers, receiving data from the Windows agent, and connecting to Linux servers via SSHFS/CIFS, etc.

It worked surprisingly well, using similar multiprocessing techniques.

Re: PHP 8

#257

Post by exikyut »

ericbarrett wrote: post #236
kostarelo wrote: post #213

Earlier quoted context omitted.

Can you elaborate a bit on what that code did? You said it a backup system talking to a MySQL? But there was a different front end and a different back end system that were both dependents on it?

Sorry, I wasn’t very clear. The backups were of MySQL databases and we stored them for a period of time (it was in the Terms of Service). When I say “back end” or “backend” I mean internal servers, that didn’t directly take HTTP requests. This means everything from databases to backup hosts to other data stores to dashboards. “Front end” means web servers that did take HTTP requests and served facebook.com. PHP devel…

Question I possibly couldn't ask a more appropriate person: how were the long-running server processes managed?

I really want to use PHP to manage backend-type, long-lived stuff... in a way that is relatively lightweight and self-managing, and idiomatically tolerates the occasional bit of unparseable syntax on script load or mis-named function call, without throwing a hissy fit.

Like... the only thing that'll typically ever knock php-fpm completely over is generally a script-triggered interpreter segfault, which is Bad™, exceptional, and (given php-fpm's collective uptime on all installations everywhere) vanishingly rare. Fatal error? FCGI response message passed upstream. Script exceeded execution time? Hard timeout (and message passed upstream). CLI SAPI? Clunk; no more script execution for you. I've always felt a bit left out in the cold by this, just in terms of how the language itself handles this edge case.

I guess I probably just stop whining and go setup systemd unit files or similar. That would definitely make the most sense in a production environment; I should probably build the muscle memory.

It's just that, for slower-paced and/or prototype-stage projects that don't have a clear direction... my brain's trying to reach for an equivalent of `php -S` that isn't there, and... I guess it's really easy to get idiomaticity-sniped, heh. ("But this project isn't a thing yet... and systemd unit files go in /etc, which is like, systemwide... and I forgot the unit file syntax again..." etc etc)

TL;DR, if this made sense :), did you ever encounter this sort of scenario, and how did you handle it? A $systemd_equivalent, language-level patches, shell script wrappers, cron, ...?

Oh, another curiosity - whenever remembering how pcntl_fork() works I usually have to reach for `killall php` a few times :) (especially when the forks are all using 100% CPU... and I accidentally start slightly too many...). How was killall isolated from nuking important server processes? Shebang line? Renamed interpreter binary (...probably not)? Different user accounts?

Thanks very much for reading :)

Re: PHP 8

#258

Post by noahtallen »

marc_io wrote: post #136
muglug wrote: post #128

Earlier quoted context omitted.

> WordPress has always been huge on backward compatibility. Yes, and I think that's ultimately the root of its challenges. A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app. I wrote this two years ago, and WordPress's basic architecture hasn't changed since: https://medium.com/@muglug/improving-wordpress-with-static-a...

> A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app. They are strongly advocating Javascript as the future of WordPress right now, so I'm not sure if they would like it to become a modern looking PHP application.

I'm working on some of these "future of WordPress" projects right now, and I don't think PHP is going away any time soon. The JS-future for WordPress is more to do with the editing experience than anything else -- the entire rendering pipeline, backend, and rest API is still PHP, and I'm not aware of any plans to change that.

The main difference with the future of WordPress is that instead of templates (which describe the structure of a site) being written in PHP, they will be written as blocks so that they are user-editable. I would say it's more apt to say that "blocks" are the future of WordPress. The block editing experience is written in JS, but serialized block markup is backwards compatible with HTML, so no JS is needed to render blocks once they are serialized.

Re: PHP 8

#259

Post by Yetanfou »

ericbarrett wrote: post #133
sigzero wrote: post #122

Earlier quoted context omitted.

Why did you switch to Python? Surely it wasn't as perfomant and you already had a working solution.

Mainly to get off HPHP and relieve both that team and ours of the constant coordination and toe-mashing. We thought “modernizing” the code would be a better investment than jerry-rigging the Zend engine back into our infrastructure. I think it was the right call. Also, with Python we could interact with other services using basic Thrift bindings, and even provide our own endpoints. With PHP, all RPCs and queries were…

> Mainly to get off HPHP

Did you consider "moving back" to PHP instead of emigrating to Python? Given that the code was originally written for PHP that sounds like the easiest way out of any problems caused by HPHP. Was it politics which led to the decision that HPHP was the only allowable PHP engine?

Re: PHP 8

#260

Post by cutler »

riteshpatel wrote: post #179
dagw wrote: post #62

Earlier quoted context omitted.

Modern PHPs shining light is the Laravel framework and the ecosystem built up around it. If you're going to start a database-driven website projects in PHP there really isn't a good reason to not use and learn Laravel (or Lumen if you want something more lightweight). That being said if you're not tied to PHP I'm not sure I'd necessarily recommend it. The obvious alternatives worth looking into are Ruby on Rails or P…

I could just never get used to Ruby syntax and how wordy it is. PHP/C/perl-style syntax just feels much nicer/more natural to write and I've never been able to break out of that. I guess it comes down to personal preference and what you started coding with.

Ruby "wordy" compared with PHP? You have to be joking. PHP is pseudo-Java in terms of verbosity. It's even worse than Java with its culture of space-wasting blank lines and fanfold doc comments.
Post reply on HN