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

21–30 of 318 posts

Re: PHP in 2022

#21

Post by cntainer »

I started my career in PHP ~15 years ago trying to do OOP in PHP 4.x. That was "fun".

In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level.

I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and some of the frameworks were trying too hard to copy the Java ecosystem, all while Java itself was starting to modernize.

I'm curious what is the value proposition of the latest PHP version(s). Why would I choose PHP when starting a greenfield project? I know one of the easiest answers is that there's a huge amount of developers worldwide that know PHP, but apart from this obvious reason is there anything else that would make someone choose PHP ahead of other stacks?

Re: PHP in 2022

#22

Post by kijin »

Syntax sugar is nice. It helps PHP sidestep the age-old criticism about its crappy API, although the crappy API is still there if you want to use it.

What's really great about PHP these days is the development environment. Composer is a rock-solid package manager. Most frameworks and important libraries are gravitating toward shared standards defined by PSRs. Thanks to those shared standards, the APIs are stable and easy to understand. There's no colors/faker/left-pad drama. Everything just works out of the box and keeps on working. Everything is extensively documented. And somehow the runtime keeps getting faster without breaking backward compatibility.

Re: PHP in 2022

#23

Post by aeno »

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 uses a garbage collector since version 5.3 that was released around 2009/2010.

Re: PHP in 2022

#24

Post by heurisko »

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 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.

Re: PHP in 2022

#25

Post by mschuster91 »

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…

> Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language?

No. While PHP won't be the language of choice for academia or some new hipster startup that wants to woo junior engineers with the promise of "we're using the latest cool shit", the trio of PHP, Java and .NET with their associated ecosystems has managed the fine balance of evolution speed between uprooting everything on the regular (like NodeJS which went through at least three major build toolings with zero compatibility and the Javascript language itself with at least four ways of creating modules) and becoming a live fossil (like Perl) pretty well.

Re: PHP in 2022

#26

Post by vaylian »

f311a wrote: post #12

It's still a language that's mainly used for web development, right? Modern websites in big companies require pretty complex backends that require data processing queues and other background activities. Can PHP compete with languages such as Go, Python or Ruby in the future?

Why shouldn't PHP be able to compete here? I personally prefer Python over PHP for stylistic reasons but I have no doubt that PHP is capable of doing the same things as Python, even if the syntax looks a bit more outdated.

Re: PHP in 2022

#27

Post by jhgb »

edoceo wrote: post #14
jhgb wrote: post #10

Earlier quoted context omitted.

So you switched from a language X not designed to do Q to a language Y designed to do Q, presumably because language Y didn't exist when you started doing Q. I imagine that happens all the time, but seldom is it a fault of X. But what I find puzzling is why PHP, of all things, was your choice for these kinds of problems before Go appeared.

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.

Re: PHP in 2022

#28

Post by viraptor »

cletus wrote: post #20

I'm a fan of PHP and have been for years for several reasons: 1. Low barrier to entry; 2. Hard to leak resources since the model is to tear down everything after a request finishes; 3. Stateless API core which means the efforts of creating an environment for a request for (2) is extremely low. Compare this to, say, the bootstrap time for Python or Java (which is why those generally don't follow the request teardown m…

> Compare this to, say, the bootstrap time for Python or Java

The bootstrap time for a request exists only in a web framework, not in the language. And since you can have the extremes of pure fastcgi or uwsgi, or full Django, you need a more specific comparison.

Re: PHP in 2022

#29

Post by Isinlor »

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…

There is a garbage collection:

https://www.php.net/manual/en/features.gc.php

> This section explains the merits of the new Garbage Collection (also known as GC) mechanism that is part of PHP 5.3.

> First of all, the whole reason for implementing the garbage collection mechanism is to reduce memory usage by cleaning up circular-referenced variables as soon as the prerequisites are fulfilled. In PHP's implementation, this happens as soon as the root-buffer is full, or when the function gc_collect_cycles() is called. In the graph below, we display the memory usage of the script below, in both PHP 5.2 and PHP 5.3, excluding the base memory that PHP itself uses when starting up.

Re: PHP in 2022

#30

Post by cube00 »

dskloet wrote: post #16
hmottestad wrote: post #11

PHP is my go to language for building simple backends that store data as json in a file and synchronize access using flock(...). There are a ton of cheap hosting providers that support PHP and all you have do to is copy your files over and everything works. I love to focus my energy on building a great frontend with React or Vue.

In the past I built a few things on Google App Engine. Honestly one of my greatest regrets in life. I ported a few to PHP so I won't get screwed again when I need to change hosting provider. Still need to port some and am dreading doing it but it will be for the better.

It's a shame companies, especially large ones with strategic architecture teams who should know better, haven't identified the short term cost savings of using cloud provider specific services is not worth the long term cost of vendor lock in.
Post reply on HN