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

261–270 of 273 posts

Re: PHP 8

#261

Post by cutler »

rcarmo wrote: post #145

I can't believe nobody has pointed out (yet) that PHP is the quintessential lambda :) That said, it's been many (many, many!) years since I moved away from it, but I'm intrigued by the state of the JIT and the current coding style (last time I checked, around 6.x, it was growing to be verbose and full of backslash-adorned-namespacing).

Yes, the worst aspect of PHP is how a lot of library code uses fully-qualified namespaces inline instead of a "use" declaration at the top of the file. I've never understood why.

Re: PHP 8

#262

Post by tempguy »

no_wizard wrote: post #237
cstuder wrote: 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-...

Reading this list reminds that nobody cares about the tech/engineering decisions of a product if it solves their use case. That is shockingly poor practice and state of a code base for a product that powers so much of the web

I would like to hire you for a nsd + unbound high performance setup are you available? it seems the email in your profile doesn't work anymore.

do you have telegram or something?

Re: PHP 8

#263

Post by ericbarrett »

exikyut wrote: post #257
ericbarrett wrote: post #236

Earlier quoted context omitted.

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

I think your first question is asking about something different than we did at the time (PHP 5.x). There was no central process that “ran” the backups—is that what you mean? There was a cron job on each backup server that started the work (systemd would do the job nowadays). The code would figure out what database servers it was responsible for and kick off those jobs, then exit on completion. Reporting and restaging to central storage was another set of crons, and so on. So though they ran for hours or days, the PHP processes had a well-defined start and terminus. The “master” process on each host started the worker children, did some housekeeping, wait()ed for hours, and took note of the exit codes. What you’re trying to do sounds a lot harder.

If you’re missing a magical command that sets up a test environment, I recommend writing it in shell, PHP, whatever, and sticking it in $HOME/bin. Or a makefile with a target so you can just run “make testserver” or the like; that way it will stay with the project. Or scripts in $PROJECT/bin or $PROJECT/scripts. Doesn’t really matter as long as it’s documented in the README and simple to execute. It’s permissible and customary to have a cleanup command, as well, if you started a background process. You could even have those start and stop commands create and then disable a systemd unit—that way you won’t have to look it up every time.

> How was killall isolated from nuking important server processes?

In general we didn’t isolate our processes against signals, because there was occasionally reason to send them. When we did send them, we sent them precisely. If a few kill -9s didn’t stop a backup then there was almost certainly a disk issue on the host and it was stuck on a kernel I/O system call, and we’d “nuke” the host (send it through a self-diagnosis and reimage cycle; cloud analogy: terminate and reallocate). It was definitely a cattle-not-pets environment. Other backup hosts would take up the slack.

Re: PHP 8

#264

Post by ericbarrett »

Yetanfou wrote: post #259
ericbarrett wrote: post #133

Earlier quoted context omitted.

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?

If we wanted to continue to run Zend we would have had to build out the entire supporting toolchain, from system package up. FB servers at the time ran on an ancient Linux distribution (I don’t remember if it was ever made public so I won’t say) with security patches and a modern kernel, so the system PHP was 4.2 or something similarly unusable. I think our server team eventually disabled the package because it kept causing problems when it was inadvertently installed.

And if we went that route, we would have had to build Thrift bindings and write all the glue code for any other internal service we wanted to talk to. They all had official client libraries, but they weren’t built for Zend anymore, and since they were frequent targets of micro-optimizations, they would no longer run on it. We would have been the sole maintainers of this alternate distribution and libraries, as well. And THEN we would have had to talk to the server team and convince them that it’s cool install this custom package that directly conflicts with some of the most important code we run that’s literally maintained by a team of PhDs and industry luminaries, but we pinky swear it won’t mess up. (Ever built a .deb or .rpm?) That would have been politics, but it never got that far.

Another team had already done the work for Python to “compile” your script and all its dependencies into a self-executing compressed file. All you had to do to talk to another service was import the client libraries, write your logic, run the packager, and ship the binary. (Very Go-like, in retrospect.) It was already widely used and well-supported, as a group effort. I even fixed a few bugs. So, for this particular niche at this particular company, PHP was a victim of its success elsewhere.

Re: PHP 8

#265

Post by samus »

BeyondLimits99 wrote: post #230
tyingq wrote: post #7

Earlier quoted context omitted.

"There's a long report on Wordpress and PHP 8 and it's not pretty" I wonder if that's somewhat on purpose. Part of the remaining stigma with PHP is that people cite bad PHP examples from WP.

As a PHP dev this is a really fair comment. I think the other reason non PHP devs think we are in the dark ages is because when they google it, our documentation looks like it's from 2010. It's a bit of a joke really.

One other thing I always found iffy is the comment section. Why is the information there not reviewed and back-ported into the documentation? Sometimes, as on the page of the `DateTime` class, they actually contain crucial details!

Re: PHP 8

#266

Post by xorcist »

tyingq wrote: post #208
xorcist wrote: post #203

Earlier quoted context omitted.

Perl avoids this problem by having contexts, a bit like casts but with easier syntax, and by having separate numeric and string equality operators.

Is there a reason returning undefined instead of true in those cases (string doesn't look like a number) would be worse?

Very few functions in Perl does that. It will emit a warning instead.

As to why that is, perhaps someone with more Perl knowledge can chime in. I suspect it has to do with undef being inconvenient for signalling failure, since its evaluation will be context dependent (an array of undef is true but a numeric undef is false).

Type conversion is built into the language at a fundamental level. Languages that borrows the syntax but not the type model can be confusing in cases, but Perl is pretty consistent once you get the basics.

Re: PHP 8

#267

Post by Zancarius »

spdionis wrote: post #253
jontro wrote: post #189

Earlier quoted context omitted.

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.

> It is well documented [...]

Yes, it's documented, but it doesn't make it any less obnoxious. IMO the thought of implicit conversion is absolutely asinine.

But, in fairness, PHP isn't the only language that does this. Python, at least, is more sane.

> and drop any string after, e.g. '1eabc' becomes 1.

In defense of PHP, it does yield a NOTICE if you attempt to apply certain operations to implicitly cast strings (e.g. addition), so there's that.

Suffices to say that while I've written PHP for years, I'm quite comfortable with its idiosyncrasies, it doesn't mean I don't find them appallingly brain damaged. :)

FWIW the identity operator (===) is also a best practice in JS for nearly identical reasons which also exhibits similar (and in some cases nearly identical) implicit casting.

Re: PHP 8

#268

Post by spdionis »

Zancarius wrote: post #267
spdionis wrote: post #253

Earlier quoted context omitted.

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.

> It is well documented [...] Yes, it's documented, but it doesn't make it any less obnoxious. IMO the thought of implicit conversion is absolutely asinine. But, in fairness, PHP isn't the only language that does this. Python, at least, is more sane. > and drop any string after, e.g. '1eabc' becomes 1. In defense of PHP, it does yield a NOTICE if you attempt to apply certain operations to implicitly cast strings (e.g…

Yes, implicit conversion in both PHP and JS are brain damaged by today standards, but that's life with legacy cruft.

Re: PHP 8

#269

Post by jontro »

spdionis wrote: post #268
Zancarius wrote: post #267

Earlier quoted context omitted.

> It is well documented [...] Yes, it's documented, but it doesn't make it any less obnoxious. IMO the thought of implicit conversion is absolutely asinine. But, in fairness, PHP isn't the only language that does this. Python, at least, is more sane. > and drop any string after, e.g. '1eabc' becomes 1. In defense of PHP, it does yield a NOTICE if you attempt to apply certain operations to implicitly cast strings (e.g…

Yes, implicit conversion in both PHP and JS are brain damaged by today standards, but that's life with legacy cruft.

Still in js "0.2" == "0.20" would always be false. My instinct would be that comparing two different strings would be false in php too.

The problem for me is working with a big legacy codebase. I'd rather have php break backwards compatibility and change === to ==.

Re: PHP 8

#270

Post by exikyut »

ericbarrett wrote: post #263
exikyut wrote: post #257

Earlier quoted context omitted.

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

I think your first question is asking about something different than we did at the time (PHP 5.x). There was no central process that “ran” the backups—is that what you mean? There was a cron job on each backup server that started the work (systemd would do the job nowadays). The code would figure out what database servers it was responsible for and kick off those jobs, then exit on completion. Reporting and restaging…

Thanks very much for replying! Apologies for response latency...

Cron jobs make a lot of sense for periodic batch work.

It's interesting you used PHP to start and manage child workers (I recall reading somewhere in the docs about PHP being unable to report error code status correctly under certain conditions, but I can't find it right now).

Regarding environment, I was mostly pining about PHP's lack of a "correct"/idiomatic way to handle genuinely fatal conditions (like syntax errors) in a way that meant the binary would stay alive. I'm suddenly reminded of Java's resilience to failure - it'll loudly tell you all about everything currently going sideways in stderr/logcat/elsewhere, but it's "difficult enough" to properly knock a java process over (IIUC) that it's very commonly used for long-running server processes.

PHP-FPM has this same longevity property, but the CLI was designed to prefer crashing. I just always wished I didn't have to bolt on an afterthought extra layer to get reliability. So I wondered if I could learn anything from this particular long-running-process scenario. Cron is hard to beat though :)

Hmm. Automating the systemd unit creation process. Hmmmm... :)

And... heh, that's right, `kill` exists. Need to step up my game and stop `killall php`-ing. Good point.

Thanks again for the insight.

Post reply on HN