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

PHP in 2022

stitcher.io

Post reply on HN
Print view View original

141–150 of 318 posts

Re: PHP in 2022

#141

Post by azangru »

mojuba wrote: post #63
dskloet wrote: post #17

Earlier quoted context omitted.

Slow change is good for small projects that you want to build once and use for decades without much maintenance.

A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die before it evolves into something sensible. Not that I believe PHP will die any time soon, but just replying to your "slow is good".

> A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die

Careful there :-) Modern javascript has semicolons and is introducing pretty horrendous syntax for private variables (an octothorpe) and possibly for the pipe operator (percent sign, was it?) and for tuples and records, yet is showing no signs of dying.

Re: PHP in 2022

#142

Post by sidkshatriya »

heurisko wrote: post #24
mojuba wrote: post #9

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…

> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. I don't see that as its biggest killer feature. In fact most projects built on PHP using a framework won't use the feature, as every request will be routed through a front controller. This has been true for at least a decade. I think the killer feature of PHP…

> I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.

I agree. Shared nothing is definitely the killer feature.

Even if php-fpm is tear down at every x requests, each request still starts afresh in which each needed PHP file is required and loaded again. This is not slow because of opcode caching means that parsing etc. does not need to be done afresh. PHP just pulls from the opcode cache. At the end of the request the request is torn down. The interpreter instance might be reused again for performance (though that may be torn down every x request also as you implied with php-fpm for instance).

When you want to find out why something did not work in PHP you just need to go back to the start of the request and work your way from here. With a stateful system like Django (Python) or nodejs (JavaScript) you need to worry about the state of the full server in addition to what happen in a specific request.

This is an ideal model of course because large PHP implementations uses caching (in things like redis) to speed things up and the cached state could be the one introducing a bug. However, in practice, PHP tries to put in most of the state in a relational db so debugging a PHP script is much simpler due to this shared nothing feature.

Re: PHP in 2022

#143

Post by Aeolun »

snov wrote: post #120
swalsh wrote: post #68

Earlier quoted context omitted.

The big guys, who know what they're doing use PHP because it makes devops stupid simple. Throw it on the server, its ready. That's always been PHP's killer feature.

Is it? Last time I used PHP (around 5.x-7.x) it was exactly the other way around. For production you needed php-fpm, nginx, opcode cache... it was a nightmare compared with go or even java. Is it better now?

I think the thing is, you install those once, and then you can run an infinite number of websites.

They also share the same resources, so even your little blog can take as much (or more) traffic than your production application.

Re: PHP in 2022

#144

Post by captn3m0 »

syshum wrote: post #42

>>Packagist, now with over 3 million registered versions and more than 300.000 packages I see PHP continues to import all of the problem of npm into the PHP community, I moved away from php about the time packagist started to gain ground.

Packagist actually gets a lots of things right that NPM gets wrong:

1. NPM has a global namespace that was shoe-horned into an organization thing later. Packagist has been namespaced since day one. Using a namespace avoids almost all of typo-squatting issues etc.

2. NPM hosts the code at its end. This means you could review some code on GitHub and it might not match the code that you get. Packagist fetches the code from GitHub (same guarantees as Go)

3. NPM: The package version is defined _inside_ the package.json file. This causes issues, because the NPM registry is not necessarily the source of truth for this data, resulting in weird edge cases, such as this bug[0]. Composer/Packagist on the other hand just syncs tags against GitHub.

4. The whole NPM ecosystem needs a whole lot of additional tooling to actually publish packages on NPM. NPM doesn't support robot accounts (PATs are not bots), so you must provide a token with complete write access to your account to your CI system, which then must build and push a package to NPM. This process being without 2FA has led to a lot of compromises. Every release also needs chores to bump the version in package.json (which doesn't have to match the version in package-lock.json). Packagist side-steps all these issues by setting a webhook on your repo (no write access needed) that can trigger a sync on Packagist end. Ideally, this should just work with an RSS feed, but webhooks are easier to build.

NPM has a lot of good ideas (ability to load multiple versions of the same package for eg), but Packagist isn't a terrible package manager - it works quite well, and you rarely see people tripping over composer like how happens with the Python ecosystem. The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally.

[0]: https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...

Re: PHP in 2022

#145

Post by dreadnip »

dotancohen wrote: post #107
dreadnip wrote: post #101

I'm glad the community around modern PHP is thriving, but filler articles like these are getting on my nerves. Reiterating a bunch of content that has already been covered extensively on the web in the past months (and in 10+ previous posts on your own blog), slapping a misleading title on it and filling it up with call-to-action's for your own personal video/newsletter/courses isn't good content. The author had some…

You're not wrong, but Brent's articles are just about the cream de la cream for PHP. I'm glad to see him on the HN front page. I've been coding in PHP since 1999, so I've seen the language evolve from not-Perl to what we have today. For maybe two or three years now I've relied on to Brent to bring me up to the newest state of the art without having to parse changelogs and release notes (which I usually get to around…

He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it.

Unlike other "x in 2022" articles (for example https://www.ncameron.org/blog/rust-in-2022-2/), this one doesn't actually give any insight into the future of the language. Not only that, but there is no original content in it. He's simply repeating what he's been writing about for the past year. Maybe he should've called it PHP in 2021? Oh wait, he already did that (https://stitcher.io/blog/php-in-2021) and it's eerily similar to this article. If there is nothing new to write about, why write?

I'm glad you bring up the PHP Annotated Monthly blog, it's a great resource and definitely one of the blogs to follow to keep up to date with PHP.

Re: PHP in 2022

#146

Post by agumonkey »

ducharmdev wrote: post #139
agumonkey wrote: post #127

Earlier quoted context omitted.

I seems to me that php/js/python will have a large consolidation in the next decade.

What do you mean by a large consolidation? As in users will coalesce around one of these ecosystems, or something else?

More like a lot of their flaws will resolve around a similar set of ideas.

Re: PHP in 2022

#147

Post by m4l3x »

jhgb wrote: post #27
edoceo wrote: post #14

Earlier quoted context omitted.

Isn't Go like 10 years old now?

More like thirteen. Apparently I misread the comment I was responding to as "for two years some time ago". Now I'm not sure why someone would have chosen PHP for such a task two years ago.

Sorry for unclear phrasing. I meant I used php from 2018-2020. And honestly I don't know why to use php for the task. I started at the company 2018 and the tech stack was given. A good compensation and praising like "PHP has changed and now supports types etc." let me take the opportunity.

My bad, because it took me a lot of time. I needed to do benchmarks were actually PHP turned out to have comparable performance in the scenario under test (concurrent consuming of message Queues and heavily write operations to databases), however it took more than 4 times the effort to get there with php.

In the end I resigned and switched to a new opportunity doing golang solving similar issues.

My point is, that there are folks out there (ab)using PHP for all and everything. And finally php has made a lot of improvements but it is just catching up with other languages. There are still a lot of libraries, that still use older versions and probably never will get updated.

Re: PHP in 2022

#148

Post by dotancohen »

dreadnip wrote: post #145
dotancohen wrote: post #107

Earlier quoted context omitted.

You're not wrong, but Brent's articles are just about the cream de la cream for PHP. I'm glad to see him on the HN front page. I've been coding in PHP since 1999, so I've seen the language evolve from not-Perl to what we have today. For maybe two or three years now I've relied on to Brent to bring me up to the newest state of the art without having to parse changelogs and release notes (which I usually get to around…

He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it. Unlike other "x in 2022" articles (for example https://www.ncameron.org/blog/rust-in-2022-2/ ), this one doesn't actually give any insight into the future of the language. Not only that, but there is no original content in it. He's simply repeating what he's been writing about for the past year.…

  > He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it.
Yes, I agree, this particular article is lacking.

Re: PHP in 2022

#149

Post by throw_m239339 »

mojuba wrote: post #9

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…

PHP is either a flawed scripting language for some or a "poor man's java" for others.

I had to learn JEE(JSP,JSF,CDi,JPA) for some project lately, so now I understand a bit more why Doctrine, Synfony and co are the way they are, coming from Go, Ruby, Python and JS... Well I prefer just writing some JEE stuff rather than using a PHP framework in that case, because I realized the Java cargo culting was just insane in the PHP community and how PHP is poorly equipped to replicate that JEE stack...

PHP isn't going away though, billions of PHP scripts out there to maintain, and CMS are built in PHP mostly because of hosting providers still defaulting to Apache servers because cost.

Nothing is too little too late though, when I read about the evolution of Java, I realize I'm lucky to suffer through it today rather than 15 years ago...

> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course.

JSP on Tomcat works mostly the same way. and nothing prevents anybody from using python or ruby, (or C++) in FastCGI mode. PHP has that whole "templating stuff" though.

Re: PHP in 2022

#150

Post by robinhood »

dreadnip wrote: post #101

I'm glad the community around modern PHP is thriving, but filler articles like these are getting on my nerves. Reiterating a bunch of content that has already been covered extensively on the web in the past months (and in 10+ previous posts on your own blog), slapping a misleading title on it and filling it up with call-to-action's for your own personal video/newsletter/courses isn't good content. The author had some…

On the contrary, I appreciate the author trying to summarize something instead of having to go through the last 10 posts.
Post reply on HN