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

A look at modern PHP

lwn.net

Post reply on HN
Print view View original

581–590 of 610 posts

Re: A look at modern PHP

#581

Post by filmgirlcw »

gexla wrote: post #179
s1k3s wrote: post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

> PHP only exists today because of legacies being maintained > people compare it to languages like Rust or Go since they consider those are "innovative" PHP is getting old enough for developers today to be unaware of the history of web development. If you don't know the history, then you haven't seen the twists and turns it has taken. If you don't know the twists and turns, then you don't see how everything from the…

Just to interject — WordPress’ origins are indeed PHP, but most modern WordPress development, especially Gutenberg — is really JavaScript. And that’s the reality, for better or worse. Many longtime WP devs are struggling with this reality.

In fact, I would posit that many of the complaints about PHP come from WordPress’s widespread usage and its slowness to adopt modern PHP features (and to be fair, I do understand that slowness. If you power such a huge portion of the web, making breaking changes to things that could impact tens of millions of sites on the name of modernization is difficult to reconcile). If/when PHP becomes just a legacy part of WordPress, it’ll be interesting to see what impact (of any) that has on the languages perception.

Re: A look at modern PHP

#582

Post by koffiezet »

alphadevx wrote: post #201
watermelon0 wrote: post #178

Earlier quoted context omitted.

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server). - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to a…

Where to begin indeed! > - No proper connection pooling with circuit breakers. PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design. > - No proper multithreading (that works in web environment) or parallelism in gener…

> PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design.

A bit ironic that you compare it to microservices, because that exact property of PHP makes it massively unsuitable for microservices and scaling, because it requires another layer in between the microservice platform handling the scaling, and the actual application.

PHP has it's uses, but I wouldn't go beyond a classic monolith or "backend/frontend" style application with it, with very little, manual scaling. If you go beyond that, you could probably manage to do that with a proper architecture and doing wonky stuff, but would it be a good fit? Absolutely not.

Re: A look at modern PHP

#583

Post by bernawil »

ainiriand wrote: post #205
watermelon0 wrote: post #178

Earlier quoted context omitted.

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server). - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to a…

- No proper multithreading Maybe you are not familiar with PHP multithreading in recent times but I have been using https://github.com/krakjoe/pthreads and works perfectly. No process forking.

Haven't been following php in years, but from back in the day I remember many different approaches trying to introduce threads and none could guarantee safety for the fundamental reason that the language itself is implemented unsafely. The runtime was done in C with unsafe features from the start. So process forking was the only sane reason to run php. I don't know how much of that is still true, though.

Re: A look at modern PHP

#584

Post by bernawil »

alphadevx wrote: post #201
watermelon0 wrote: post #178

Earlier quoted context omitted.

Where to begin? - No proper connection pooling with circuit breakers. - No proper multithreading (that works in web environment) or parallelism in general. - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server). - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to a…

Where to begin indeed! > - No proper connection pooling with circuit breakers. PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design. > - No proper multithreading (that works in web environment) or parallelism in gener…

  I once asked Rasmus about this face-to-face, during one of his presentations, specifically his thoughts about the pThread extension (https://www.php.net/manual/en/intro.pthreads.php), and he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.
if each web server thread that serves a request ends up spawning a full PHP process then it's not a mute point.

  pretty hard to proceed with some code that works with a DB when the connection can't be established, so proceed with what exactly other than error handling?
proceed with all the rest of the bootstrapping code in parallel instead of blocking and waiting for each.

  is a synchronous thread, as described above above. By design.
it's a synchronized full forked process. Because the runtime was written using memory unsafe C features from the start. By design doesn't excuse it being a bad design.

Re: A look at modern PHP

#585

Post by gexla »

filmgirlcw wrote: post #581
gexla wrote: post #179

Earlier quoted context omitted.

> PHP only exists today because of legacies being maintained > people compare it to languages like Rust or Go since they consider those are "innovative" PHP is getting old enough for developers today to be unaware of the history of web development. If you don't know the history, then you haven't seen the twists and turns it has taken. If you don't know the twists and turns, then you don't see how everything from the…

Just to interject — WordPress’ origins are indeed PHP, but most modern WordPress development, especially Gutenberg — is really JavaScript. And that’s the reality, for better or worse. Many longtime WP devs are struggling with this reality. In fact, I would posit that many of the complaints about PHP come from WordPress’s widespread usage and its slowness to adopt modern PHP features (and to be fair, I do understand t…

> but most modern WordPress development, especially Gutenberg — is really JavaScript

As are probably most other discussed ecosystems in this thread. Most people doing Go for web development are probably writing JS heavy front-ends which interact with API endpoints on the Go driven back-end.

> If/when PHP becomes just a legacy part of WordPress, it’ll be interesting to see what impact (of any) that has on the languages perception.

What would it be replaced with and why?

Gutenberg still interacts with a PHP back-end. There will always (until web drastically changes) be a need for something to do the API handling. Would Automattic push the community to build that back-end using Go? Node?

Re: A look at modern PHP

#586

Post by thrusong »

infamia wrote: post #276
thrusong wrote: post #261

I've been programming in PHP since 2007 and I absolutely love it. I've long ignored the hate for it here. I worked hard and followed best practices to get good at PHP. In 2015, I started writing "projectionist" software in PHP to completely automate my home theatre. I was a projectionist at three different theatres for about half a decade. I spoke with old-timers to really get it right and have been tweaking this scr…

This is fantastic! Do you have a code repo somewhere?

Unfortunately, no, I haven't published the source code. I'd maybe like to commercialize it in the future, but it would require either some tech to compile PHP or would need to be re-written.

I think it's a really simple system overall... It uses XMPPHP (updated for PHP 7) and otherwise it's just a lot of loops, network calls, and proc_* functions.

Re: A look at modern PHP

#587

Post by KerryJones »

Ayesh wrote: post #559
KerryJones wrote: post #480

As someone who has programmed PHP professionally for 13+ years (and also JS and Python) I have never run into anyone who can place a solid argument since the PHP 7 + Laravel. -- Let me clarify, PHP is useful with context. For building web apps. Each language has its best-uses. Laravel has the strongest ecosystem and community out of any language/framework combo I've seen. I can literally setup and deploy a laravel ap…

All my projects require PHP 7.4, and it's such a joy to write the modern almost-strict typed, namespaced, and code that is often inter-operable, tested with a nice testing framework, and managed with an excellent dependency manager. I have my reservations against Laravel though. Its excessive use of static methods is not my appetite, and its rapid release cycle gives less headroom to keep track in contrast to Symfony…

What's wrong with the static methods? And do you mean beyond helpers?

Laravel gets a major update about once a year from what I've followed (disclosure: I've been to Laracon twice, you could probably classify me as fanboy) -- I _haven't_ used Symfony, but I have enjoyed the rapid release cycle of Larave. It also generally takes 20-30 minutes to update to the latest major release, and if not, there is a service for $10 or so to update it for you

Re: A look at modern PHP

#589

Post by marcosdumay »

AegirLeet wrote: post #558
marcosdumay wrote: post #507

Earlier quoted context omitted.

What do those mean? > Hashing > Encryption > CLI commands with option/argument parsing, colored output, progress bars etc. (Do you mean a management console? All of them have it.) Except for those, Django has every single one.

Hashing: Support for securely creating and verifying cryptographic hashes, like you'd need for password hashing. Encryption: Support for securely encrypting, signing, decrypting and verifying arbitrary payloads. In Laravel, you can do: $plaintext = 'foobar'; $encrypted = $encrypter->encrypt($plaintext); // this will encrypt the plain text, generate a MAC and combine everything into a base64 encoded payload $decrypted…

You mean, an crypto library exported by the framework instead of you specifically importing it? I don't see the gain (as a consequence, I have no idea if other frameworks do that).

RoR and Django both have extensible management commands, and all frameworks that I have ever seen allow you to create independent CLI commands (it's on PHP that the CLI is a second class citizen).

Re: A look at modern PHP

#590

Post by xd »

phaedryx wrote: post #403
stunt wrote: post #200

Earlier quoted context omitted.

Most of the comments against PHP are from developers that wrote PHP There are still some issues but considering the current state of language, frameworks, libraries, and the ecosystem, it's very practical and productive environment to build any project. I've been doing Typescript, Scala, and recently also Go in last few years. Scala and Go have decent language design and I'm a fan of both of them. But, when it comes…

PHP 4 was the last time I wrote any PHP; I hated it. You are right, though. PHP now is not the PHP I knew.

One of the great things about PHP is the development has always taken backward compatibility into mind.. so while true it's not the PHP you know, it still pretty much knows the PHP you knew.
Post reply on HN