PHP 8.2
php.netThe worst part about PHP is constantly hearing from its detractors, who are often people who haven’t used the language in many years. Haystack needle order, $, fractal of bad design, it just gets old.
The language isn’t perfect but I love working with it, these 8.1 and 8.2 improvements have really made it sweet.
My biggest gripe at the moment is the (very old) behavior of e.g. preg_match() and sort(). You’ve got a small handful of these common functions that operate on their input by reference/in place which is gross. A new version of these would be welcome.
The truth is, no language is perfect.
PHP just happens to be good at getting stuff done fast, so it's found all over the place, and thus has a lot of eyeballs on it. The negativity is a byproduct of it's usefulness and staying power - the price of popularity, if you will.
I love PHP, especially with the new event loop based modules that let you do things asynchronously, much like Node or Go.
If you know how to use it well, PHP is awesome, and it's getting better with each release.
PHP was the first open source language in which just anybody could write server-side web applications without terrible management problems for the sysadmin. First people wrote cgi-bin scripts in Perl, which were not efficient because they forked a process for each request. There was mod-perl which was more efficient but prone to memory leaks. A few people wrote cgi (or fast-cgi or Apache module) programs in C/C++ but that was insane since a return after a 𝚜𝚝𝚛𝚌𝚙𝚢 is Turing complete in C and there weren't any mitigations for this in the 1990s.
PHP opened the door to cheap web dynamic web hosting and in turn you had self-hosted applications like Wordpress. It was a few years later that languages like Java and C# became really attractive for back end work, you also had Ruby, Node, etc.
I wrote a lot of PHP in the early 2000s because that is were the work was, that’s what you could write open source code that people would use in, and it was really straightforward to build apps (like a social network for a secret society) without an ‘ops’ team watching your every move.
This is a refreshingly nice, informed, and balanced perspective.
I've only done PHP for small personal projects and some wordpress hacking, and that was years - so my experience is limited. But it seems to me that one of the great and tragic things to PHP is the low barrier to entry. As you put it: "first open source language in which just anybody could write server-side web applications without terrible management problems for the sysadmin".
This made it extremely easy for anyone in the early 2000s who signed up for a web hosting account on godaddy/hostmonster/hostgater/etc... to fire up a text editor of their choice and start slinging code and FTP'ing up to a server. Didn't have to worry about installing, configuring, all the dependencies, build tools, etc... just edit, upload, refresh -- lather, rinse, repeat until it works. Lowered the barrier to entry, and got a lot of people into the field. Really powerful stuff.
It also made sloppy, hacked-together, copy-pasta code very prevalent. In my limited perspective, I suspect that this prevalence of sloppy spaghetti-code has contributed to PHP's bad reputation. It's not that you can't do good code (totally can!), but a PHP environment can be forgiving of some pretty bad practices.
The thing is, I've seen sloppy, hacked-together code in finance, in a variety of languages, including Java and C, where the barrier to entry is relatively high, and the language fairly strict. You just don't hear about the coding fiascos, as they're mostly behind closed doors.
PHP has a low barrier to entry, but that's a great thing in my opinion. It's something that should be celebrated, and at the very least, it shouldn't be a criticism!
Bad developers exist in every language, and no language is completely wart-free. People just like to zero in on PHP to criticise it because it's easy, and it bugs me a bit (especially if they're simultaneously singing the praises of another less than perfect language such as JS or Python or Go).
PHP had the advantage of having built-in resource limits and little contention over locks and other shared resources that meant sloppy coding wouldn't crash your server. Providers could offer low cost hosting plans because you could put a lot of customers on the same server and have very little trouble. It was a big plus that it was open source and didn't have the crazy high license costs of early dynamic web hosting solutions such as ColdFusion, WiTango, Netscape's application server, etc.
In my mind the great thing about PHP was packaged application software like PHPNuke, Wordpress, etc. that would let you make a highly capable dynamic site with little or no coding.
At that time you could have made similar software for JSP, ColdFusion or ASP.NET but hosting would have been much more expensive and a big hassle. With PHP it was feasible to offer a $5 a month hosting plan good enough for blogs and simple web application.
I wrote a lot of PHP because it was a great way to deliver products to customers, particularly ones that didn't have a lot of resources for "ops" but also a place where I could write open source software which might really get used and have an impact.
I think the big thing PHP offered was people could easily deploy their project just by copying files to a directory. A link directly to the file got dynamic content. Most shared hosting also put index.php in the default indexes to check for directories. So it was simple to have clean looking links without using a rewrite module.
Deploying to the cgi-bin directory was more convoluted and error prone for end users. Even when you did it right all of your URLs had an "ugly" cgi-bin component.
The easy deployment and cheap shared hosting with their managed MySQL instances really helped boost PHP's usage.
"First people wrote cgi-bin scripts in Perl, which were not efficient because they forked a process for each request"
I don't recall the sequence of events that way. That is, there was regular cgi, then mod_php with problems similar to mod_perl...then later fastcgi options existed for both.
Wait. Isn't fastcgi essentially the same as mod_php? IPC with a long-running process rather than forking and capturing stdout?
What's the newer fastcgi php method that isn't mod_php?
The mod_* meant apache modules managing the process pool without a socket connection to a separate pool manager. Which meant issues there could affect the webserver, which was typically also serving static assets, etc.
You're right, I guess I misremembered how I set my web server up. I'm using mod_proxy_fcgi with php-fpm, not mod_php.
FastCGI and mod_php are both ways of running PHP on a web server, but they differ in how they achieve this.
FastCGI is a protocol that allows a web server to communicate with external programs that provide dynamic content, such as PHP scripts. In FastCGI, the web server launches an external program, called a FastCGI process manager, which is responsible for starting and managing a pool of long-running PHP processes. When a request for a PHP script comes in, the FastCGI process manager assigns one of these processes to handle the request, and the process generates the dynamic content and sends it back to the web server.
mod_php, on the other hand, is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that PHP scripts are executed directly within the Apache process, without the need for an external process manager.
While both FastCGI and mod_php are ways of running PHP on a web server, they differ in their implementation and how they handle requests for PHP scripts.
Is there no rule about GPT/bot responses on HN?
We don't allow bots on HN and ban such accounts.
One ChatGPT reponse to:
> Write an explanation for the user who posted the following comment: "Wait. Isn't fastcgi essentially the same as mod_php? IPC with a long-running process rather than forking and capturing stdout? What's the newer fastcgi php method that isn't mod_php?"
is:
> FastCGI and mod_php are similar in that they both use a long-running process to handle PHP requests, rather than creating a new process for each request. However, they differ in how they are implemented and how they interact with the web server.
FastCGI is a protocol that allows a web server to communicate with external programs, such as PHP, to handle dynamic content. It is typically used with web servers such as Apache or Nginx. In the case of PHP, the web server uses FastCGI to send PHP requests to a PHP-FPM (FastCGI Process Manager) process, which then executes the PHP code and returns the result to the web server. This allows the web server to handle multiple PHP requests simultaneously, improving performance.
On the other hand, mod_php is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that Apache can handle PHP requests itself, without the need for external programs or FastCGI.
Fact that PHP was built-in on virtually every Linux distribution and hosting was dirt cheap since one server could easily host hundreds of customers helped too I guess. Java and .NET never were after the $5/month hosting market.
> PHP just happens to be good at getting stuff done fast, so it's found all over the place, and thus has a lot of eyeballs on it. The negativity is a byproduct of it's usefulness and staying power - the price of popularity, if you will.
I don't like arguments like these because they're a tu quoque without even bothering to point out flaws in a different thing. It implicitly states that progress is impossible, that all languages will always be as bad, and nothing can ever improve because once a technology is widely-used, design flaws will magically appear. If you really believe that, write your next website backend in FORTRAN IV.
It was lazy argumentation when it was people saying Linux was just as buggy as Windows Me and it's lazy argumentation now.
I accept PHP has flaws, as do other languages. But I feel PHP gets an unfair amount of criticism, given that it's "flawed" implementation of a programming language happens to run a big chunk of the web today.
> Progress is impossible
Huh? My very last sentence implies quite the opposite.
> It implicitly states that progress is impossible
PHP has made huge strides in progress over the last decade.
Have you considered that these "detractors" might just be former users of the language themselves, who felt liberated once they tried something else, and want to help other people not feel stuck as well?
Right but if someone stomped in here talking shit about for example javascript's verbose function notation, poor linting tools, and lack of type checker we'd be like what year are you from? We all got burned by that stuff, we all hated it circa 2016, it's all been addressed now. Javascript still has problems but those aren't it and any conversation about it includes that nuance.
Php is in a very similar situation, the difference is you can't escape javascript so we all to some extent keep up with its developments. People who leave php left it at a certain point and their understanding of its issues is frozen there. It's very predictable and boring honestly.
Since when does PHP not have $?
What's the problem with '$'?
For me, it makes code harder to read because my brain can't stop pronouncing it as “s”, so something like `f($x, $y, $z)` reads like “eff sex, swy, szee”. And for writing, requiring a shifted key before every identifier is a lot of pinky strain. Not to mention that it's completely useless noise.
But it lets you do things that are absolutely wild without weird syntax or setting up reflection. $obj->$dynamic_var. Or $$dynamic_obj->$dynamic_fun().
Whether or not you should be doing that is another matter… but it’s useful in some cases and easier to grok than using reflection or using array syntax on an object (like JavaScript).
After awhile, you don’t even notice the $ to be honest.
It must be embrassing when you read outloud "S-S-SWone thousand dollars".
Life is too short to care about stuff like this. It's like saying you don't like the color blue.
Carpal tunnel syndrome is nothing to take lightly.
I did php and moved to other languages. I don't feel liberated.
In fact php with composer and tooling is really good these days. Most people I've met (in person) who hate on php can't say why. They tend to equate php with wordpress.
I've picked up their projects and see many problems but I don't go blame the language they chose.
For the order of function arguments: sounds like you'd enjoy https://github.com/azjezz/psl.
Yes it's a userland workaround and not a fix for the language, but it's thinking about these issues and a PHP extension (offering better performance) is being talked about.
Yep that's a great library, I'd like to see some of it in core. Same with this: https://github.com/lstrojny/functional-php which overlaps somewhat.
The no-brainers to me are the missing array_some()/array_any() array_every()/array_all() and an array_search() that takes a predicate and iterable. I do these now in userland but an optimized native version would be nice.
PHP 8.0.0 introduced named arguments which allow for arbitrary argument order. That was nearly 2 years ago exactly to date.
What does that lib do that PHP doesn't?
That lib probably makes any seasoned php dev really confused or think everything is backwards and somehow still works.
> The worst part about PHP is constantly hearing from its detractors
Does it deterministically pass ALL tests in its own test suite yet? 100% of the time? This was the state just a few years ago, where a lot of tests were simply disabled because they were "flagging". <insert eyeroll emoji> (I'm not even going to touch the Boolean chart showing the different behaviors of single, double, and triple-equals on results. I know a lot of that has been fixed, at least by "convention".)
Nondeterminism is literally the worst trait of a computer language, because it leads to the worst kinds of bugs- the ones that are NOT a result of your lack of understanding of how the code is supposed to work at the PHP level. I've literally burned months away in my career in tracking down bugs like this (in Ruby and other languages), which ended up being framework or language bugs. There comes a point when you say "never again". Unfortunately, it comes too late in most people's careers to realize they've made a mistake, and switching to another language/community becomes too expensive/risky a proposition for them. (In my case I've been fortunate in that I was able to switch from .NET, to Ruby, to Elixir... each one of these was a difficult transition, both intellectually and socially (I really miss the Ruby community!), but in the end, completely justified in my case.)
Is there still a php.ini that allows you to alter the language’s semantics? To me, that’s the biggest can of worms that PHP used to have. I haven’t touched it in years, so am not up to date.
Not really. You have a php.ini that can configure some behavior, but most of what was horrible is either deprecated or straight up removed (register globals, ...)
assert() is still broken if it's disabled in php.ini.
I mean yes php.ini allows you to disable any function you want, and if you do that then this function doesn't work like expected, I can hardly blame php for that.
Yes, that's fully true, but does specifically assert() falls into that category?
> assert() is still broken if it's disabled in php.ini.
Care to explain what you mean it's broken if disabled? That it is disabled (noop in runtime) so you're missing it? AFAIK that's the production setting. You should be able to enable it in build/test/ci/development, just how you want it.
Sure. (1) it is a global setting so I can't decide if I want it on a per application basis, with Docker that is less of an issue though (2) it is disabled by default, so hardly anyone uses it from what I see (3) I'd like to have it always enabled, also in production, so my code doesn't end up in states that I didn't expect and I get notified.
But that might just be me and/or my particular use case.
Yes. Looks like the canonical use if for ENV vars though?
There are two types of programming languages: Those everyone complains about, and those nobody uses :)
> My biggest gripe at the moment is the (very old) behavior of e.g. preg_match()...
Do you mean how you can have an optional out parameter to get more detail than what the return parameter gives for which group matched?
Personally i dont see anything wrong with that, but to each their own.
People don’t realise that it powers the majority of sites on the internet. It’s got a bad rep from security flaws in the late 1990s. Things have moved on since then. It does the job.
There's less and less wrong with it as we go along, but seriously there's still so much crap... You could list so many other than preg_match
>sleep(int $seconds)
>returns zero on success.
>If the call was interrupted by a signal, sleep() returns a non-zero value. On Windows, this value will always be 192. On other platforms, the return value will be the number of seconds left to sleep.
I've used it for 2 years 2 years ago and I'm not at all interested in starting a project with it again
A little weird, but it was documented.
PHP is nothing if not amazingly well documented. This is more than I can say for a lot of languages I have worked in cough Ruby cough. I work pretty heavily in Go these days and even it’s docs leave me wanting in comparison sometimes.
If documenting was enough band saws would still just have warnings about fingers in their manuals instead of guard rails. "Weird functions" need to have big yellow warnings at the top of their doc with a link to fixed versions of the func
It is well documented but the comments in the documentation are seriously bad most of the time. I really wish they would at least designate the primary release at the time of the comment, if not purge old ones (the comments from 2005 don't often offer much value nearly 20 years later)
You must have more than just 'sleep' bothering you. What would you start a project in today?
When I was using it, I had a novel's worth. Now I mostly forgot my rant
The projects I start today got the php replaced by typescript
In my experience, this is a highly useful feature. I’m not sure what you’re complaining about here, but if the server is shutting down, what’s the point in sleeping?
Wait, what's wrong with that?
There are 2 issues they might be complaining about: (1) cross-platform issues that seem so trivial that documenting them was probably more work than fixing them and (2) high-level language leaking low-level implementation details.
As for the second part, I understand why system calls are interruptible, particularly before the implementation of many syscall-level asynchronous operations. However, too many languages require too much boilerplate in the much, much more common case where the developer wants the appearance of an uninterruptable system call in a multi-threaded and/or multi-actor program.
I've written plenty of interruption-safe sleep and I/O code in C. It's disappointing that same C boilerplate needs to be used in PHP, Java, etc. If you want to expose the interruptiblity of a C sleep(), call it interruptible_sleep(), and make sleep() a wrapper that contains the boilerplate you want 99% of the time in C. I dare say 90+% of programmers don't properly deal with interrupted sleep system calls, and exposing the interruptions should be opt-in.
In retrospect, at the syscall level, the C library interface to interruptible syscalls should take a function pointer to an interruption handler that returns a boolean as to whether the syscall should be transparently resumed. Passing a null handler should result in the syscall appearing uninterruptable to the calling code. Most programmers are blissfully ignorant of interrupted syscalls and are perplexed by seemingly random resultant bugs. The default interface to these calls should protect the programmer.
// sleep(int sec) should look more like: void sleep(int sec) { sleep_interruptible(null, sec); } void sleep_interruptible(bool (*handler)(int), int sec) { struct timespec ts = {sec, 0}; int prev_errno = errno; errno = EOK; while (nanosleep(&ts, &ts) != 0 && errno == EINTR) { if (handler != null && ! handler(errno)) break; } errno = prev_errno; }>I've written plenty of interruption-safe sleep and I/O code in C. It's disappointing that same C boilerplate needs to be used in PHP, Java, etc. If you want to expose the interruptible of a C sleep(), call it interruptible_sleep(), and make sleep() a wrapper that contains the boilerplate you want 99% of the time in C. I dare say 90+% of programmers don't properly deal with interrupted sleep system calls, and exposing the interruptions should be opt-in
I get where you're coming from, I think the way I'd think about it would be a little different. The interruptible part is semi-specific to sleep. I'd want predicable naming for syscalls first and foremost. So something like libc_sleep(). (libc_open(), etc would follow too) This makes is more obvious you're dealing with a pretty raw api. But otherwise agree. I haven't written any PHP in nearly 20 years, so I completely forget: is sleep() pretty typical of how PHP treats these syscalls?
Why 192? Why only on Windows?
Because that's how the underlying syscall works?
I feel the same, but for Java.
Yeah, the `InternalFrameInternalFrameTitlePaneInternalFrameTitlePane MaximizeButtonWindowNotFocusedState` jokes get a bit old.
Non-java devs think of java as Java 6 when in reality it has pretty significantly evolved in the last decade. I dare say that it's one of the most rapidly evolving mainstream languages on the market at this point.
Most Java devs are on Java 8, because of how much Java 9 broke reflection, classloading, etc.
That's something that will likely change pretty rapidly. Springboot 3 is forcing Java 17 which is going to force a lot of conversations once 2 is fully retired. (free support for 2 ends next year)
The Java 8->11 transition was rough but honestly after that we've not really experienced a whole lot of pain. 16 has been a little bit of a pain as well since it closed some more unsafe holes. I think that's the last release, however, that's going to cause major headaches with migrations.
I think Kotlin will see a nice rise in adoption, as the refactoring seems big enough to warrant moving to a language that embraces certain semantics and remove some magic.
I'm speculating though.
Kotlin, IMO, is experiencing the Ruby on rails effect. It's getting strongly associated with android development which has somewhat stifled general uptake of the language.
Java has been slowly adding the best kotlin features (such as data classes, records) which also makes it a bit harder to sell.
That said, I've introduced kotlin on a few teams and pretty much everyone that's worked with it has complimented it.
Learn SugarCRM which is built on PHP; SugarCRM devs are rare, in high demand, and very highly paid (I just hired a full remote sr php dev at 145k with full benes/10% starting bonus).
We’re always looking btw.
How would you learn it though? It seems to no longer be open source as of 2013(?)
SugarCRM provides online training but it's not public.
How we train our dev's is to use those courses and to have our current PHP/Sugar dev mentor them on the differences.
That's lowish to mid $$ for a senior dev (at least in the US).
FAANG-level pay is the exception.
FAANG level pay is well over $200 for a senior, easy. There's plenty of companies offering senior comp in the 150-200 range that aren't faang.
Total comp yes, not salary like OP is talking about. Only a handful of companies have total comp that doubles base thanks to RSU and stock, which a vast majority of the worlds ~25MM programmers do not participate in.
Nope, I mean base salary not total comp.
It's amazing how skewed the HN crowd is on developer comp. You'll find that $140-150k is senior range for a vast majority of the U.S. software engineering market.
Now you're just moving goalposts. 140k is not "very high" pay for a senior software engineer anywhere in the US.
Can you share a FAAANG job ad for a PHP guy - fully remote - at $200k or more? I'm genuinely curious if that is a thing.
Or even which of those companies even hire PHP devs anymore?
Can I work remotely?
hi
Hello!
> I love working with it
Great! Keep using it! Ignore us. We (detractors) also had to use it and have since learned (hopefully several) other languages that (not looking at you JS) we like much better... :)
Curious about something.
If you've long moved on and are no longer using PHP, why do you still consider yourself a "detractor"?
For me PHP 4 and 5 was an experience that left me feeling gross. I had to go home and work on personal projects trying to figure out a way to write beautiful code to offset the ugliness I encountered every day at work.
I still occasionally work with PHP for WordPress and it is still mostly not great. The mess of abstractions, the JS-like library installation system, the lack of any kind of concurrency, the mess with errors vs exceptions.
It just isn’t a language that makes me happy. Then again, I dread opening a .php file so maybe it’s a preconceived notion.
It's the 'wordpress' part of PHP that is 'mostly not great'. Projects started in the past few years with any major framework will generally be cleaner and easier to understand, and easier to extend with composer/psr interop.
I think you're putting too much faith in frameworks there. My employer's large PHP application is written in a framework that was once popular but then was abandoned years ago. Since that framework defines every aspect of the application, down to the directory layout, migrating away from it towards a more recent framework is largely impossible at this point. While it's true that the framework is "easy to understand", it's also true that it encases the application like a concrete coffin.
Libraries are infinitely preferable to frameworks if you want your application's life cycle to be independent of $POPULAR_FRAMEWORK's.
Even with Laravel, which is the current thing in the PHP world, I've worked in multiple teams where their application is written in a very old version of Laravel and there's no desire to attempt an upgrade to the most recent version.
Outside of 'frameworks', I've tied projects to specific libraries that also were abandoned, and it's no better. Having every single query/dataaccess go through an abandoned library is not all that much different from an abandoned framework, imo.
For better or worse, there's some degree of 'upkeep' that has to be done with any code, if only to take advantage of some newer tooling (even ignoring security and performance concerns).
> and there's no desire to attempt an upgrade to the most recent version
That seems to be a problem there. I would not want to be using, say, Laravel 4 in 2022. Nor early Symfony, or any other framework (or library) that is years out of date.
What's been interesting to watch in Symfony and Laravel is to see an ecosystem grow around them which amplifies the value of using that framework (laravel shift springs to mind, based on your example above).
The danger seems to be in being complacent, regardless of tool choice. I've had to go back to Java/Spring code I wrote 10 years ago, and it's... challenging to make some things run again.
> Outside of 'frameworks', I've tied projects to specific libraries that also were abandoned, and it's no better. Having every single query/dataaccess go through an abandoned library is not all that much different from an abandoned framework, imo.
Isn't it better to tie projects to specific libraries rather than frameworks because it should be easier to swap/replace a library than the whole framework ?
(Or is that OOP kool-aid I still taste ?)
using an ORM "library" was just as problematic, because data access is something that gets fairly deep in to a project. Had we tied the project to, say, symphony, there would have been a better upgrade path (but that brought its own set of challenges). We adopted a few libraries instead of "a full framework" but when the libraries are abandoned... you still have a lot of work to refactor.
I believe we are talking about the same thing but I lack the experience of projects big/complicated enough to really grasp the difficulties.
What you should always do is to write your own code outside of the framework and pass in values or plain class objects from the framework to your code to avoid that the framework taints the entire project. One of the most common polluter is the ORM becuase it often passed to every layer of the application. And it is never too late to start.
What was the motive behind this post? What do you hope to gain?
If it's recognition for learning <insert-language>, how do I provide it to you?
Something that is extremely common in the PHP community, and pretty much absent in any other programming community, is this knee-jerk aversion to the idea of learning another language, and this sort of derision to those who do.
Have you consider that people who learn other programming languages are not doing so in order to claim that they're better than PHP programmers, but for their own intrinsic reasons?
It's such a weird, fragile ego situation. Does everyone else have to pretend that PHP is the only language that exists in order to placate your sense of inferiority?
> extremely common in the PHP community?
If I'm going to guess is that you have interacted with non-professional and/or beginner level PHP programmers, they could feel threatened becuase the only development skill they have is rudimentary PHP and you are asking them to replace that with something much more difficult. I have seen some of it myself, and it has always come down to lack of skill.
And this makes sense why you have encountered this within the larger PHP community, becuase PHP is an easy to learn beginner friendly language that is used by the majority of blog and forum systems, zero setup web frameworks, and all of it can be set into production on almost every server on earth. Thus there are many low skilled PHP developers, probably more than moth other languages.
And this is the lessons, it is important to understand that every community consist of large variety of disparate groups, especially within the PHP community, and it is up to you to learn to distinguish them. Unfortunately many are blind to this when it comes to the PHP community, outsiders may think the work I do professionally is the same as someone setting up blog for the first time, just because we use the same language. It would be same to think that the result of a first grader learning to write is the same thing as Tolkien's writings becuase both are in English.
Let's recap: post about PHP, ex-PHP user posts completely false info.
Your reaction: "why do PHP devs get upset when ex-PHP users write false things about the language? Also, none of you know any other languages".
Thanks for the ad-hominem, that concludes this discussion.
Also, plenty of people who use PHP know so many other languages. You don't appear to be a professional in this industry, especially not with this kind of discourse.
Take care.
To be clear, I never said that PHP developers don't know any other languages, and I don't believe that is true.
My comment was in response to you asking whether the other user (who as far as I can tell was not posting any false information about PHP, just pointing out that they personally preferred other languages?) wanted _recognition_, from you personally, for having learned some other language.
This is such a weird reaction to have to the idea that someone has learned, and/or would rather use, some other language. I hope you can see that.
Of course, it's not just you. I have never seen any programming language community that feels _threatened_ by the idea of other languages existing and being learned, in the way that the PHP community does.
Fundamentally, this is a learned social behaviour, which means that whether or not individual PHP developers know other languages does not matter. A community that treats acquiring additional knowledge as a _threat_, seeing learning from the outside world as a _betrayal_, will not be able to learn _from_ other languages.
As bringing new ideas and thoughts into the community is socially discouraged, it will only be possible for learning to flow in one direction: away from the PHP community.
> who as far as I can tell was not posting any false information about PHP
I asked what prompted the person to type that kind of reply. Had you read the entire topic, you'd see plenty of false info being posted, but my point remains: you used PHP, you moved on, what prompts you to be active in topic about PHP where all you contribute with is "I moved on."
> This is such a weird reaction to have to the idea that someone has learned, and/or would rather use, some other language. I hope you can see that.
And we're in territory of mental gymnastics now :)
You think the reaction is to learning another language? You're obviously a programmer. Can you tell me how many possible outcomes exist and how come you chose this one in particular?
Reaction was not to learning another language, it's ridiculous.
> I have never seen any programming language community that feels _threatened_
You never read linux mailing list and c vs c++? I can't take you seriously, you talk as if there exists de-facto "community". There isn't one, it's just a bunch of people who use various forums and there's no coherent community. You interacted with several people and you label that community and then you purposely shove words that haven't been written only to challenge them.
It's a straw man argument.
You persist in labeling PHP devs so narrow-minded that they chase away people who learn other languages. I don't know which (human) language I need to use, but it's apparent that this is becoming multiplayer monologue. I write one thing, you claim I wrote something else and then you generalize based on it.
Notice: I haven't tried to provide my "credentials" by listing what languages I know or what I do. I never even stated I'm a PHP dev.
You, on the other hand, labeled me and entire PHP community as weak-ego, tribalists who frown upon other languages and that the PHP community, which apparently you researched somehow, is different to all other communities - which you also apparently researched. In this whole wall of text you wrote, you have't asked a single question. You merely stated something and then you proceeded to take up the higher moral ground and then demean people. Do you think such discourse is productive?
> Fundamentally, this is a learned social behaviour, which means that whether or not individual PHP developers know other languages does not matter. A community that treats acquiring additional knowledge as a _threat_, seeing learning from the outside world as a _betrayal_, will not be able to learn _from_ other languages.
In this very topic, I wrote about features I'd like to see in PHP - one being generics. Something I learned in C# and something that changed my entire stance to JS because of having used in TypeScript.
That's just _one_ example of how you assume without zero facts to go by. I won't bother listing what we do for feature suggestions in PHP, which languages have great features and what we do to bring them in. You're just incapable of reading and you merely recognized me as a "bad guy" because I called someone out. I seriously doubt you'll read this, it would take more than 13 seconds of attention and that's something hard to acquire these days.
TL;DR: nice gaslighting and straw man, thanks for ad-hominem, I wish you well in the new year :)
I'm done with replying to this, but just to be clear, none of this is an ad hominem, and a generalization is not a straw man. You should probably look up what those words mean, they're not just magical words you sprinkle on a sentence to win an argument on the internet.
> Had you read the entire topic, you'd see plenty of false info being posted
I've honestly looked through all of the original poster's comments and couldn't find any misinformation. Except for referencing r/lolphp, which is indeed mostly wrong about everything.
> You think the reaction is to learning another language? [...] Can you tell me how many possible outcomes exist and how come you chose this one in particular?
I thought so, although I see now that I was wrong. I still don't understand what else your response, saying "Do you want recognition for learning other languages?" to a comment saying "I no longer use PHP and I have learned other languages that I actually like", was supposed to be reacting to, but I take it that there are other possible interpretations that I'm not grasping here.
> you talk as if there exists de-facto "community". [...] it's just a bunch of people who use various forums and there's no coherent community
Obviously a community as big as the PHP community is always going to be, in turn, fragmented into smaller communities. Symfony is not Laravel is not WordPress. But that doesn't mean that you can't draw generalisations from it, like how you would say "the Python community is scared of big breaking changes". This doesn't mean that every single member of that community is personally scared of big breaking changes. It's a generalisation about the behaviour of a group that doesn't extend into a judgement of each and every one of its members.
> You, on the other hand, labeled me and entire PHP community [...] which apparently you researched somehow
I thought there was no such thing as a PHP community. I described a general vibe that I perceive from a given community, which I have extensively interacted with and been a part of. Unless it doesn't exist, in which case I suppose I haven't.
I then compare it to other communities, which I have also interacted with and been a part of, if they indeed exist. My perception nonetheless may be flawed, and it does not need to apply to you specifically.
> I wrote about features I'd like to see in PHP
It's great that what I said above does not apply to you. Your personal appreciation of other programming languages' features, in turn, does not change what I perceive as the broader community's culturally enforced commitment to willful ignorance.
PHP is simply awesome, so much so that I have to make a huge effort to remember that other backend languages even exist.
The biggest issue with php is the developers. Many of whom are totally oblivious to engineering practices and just reinvent the wheel. 1 in 5 still debate setter and getters while the rest still argue over using spaces over tabs. All in all a very toxic culture.
> PHP 8.2 is a major update of the PHP language.
Major update, awesome. /s
As someone who manages a network of 250+ WordPress websites - these PHP updates are killing me! As soon as I'm done helping clients upgrade/fix their incompatible themes/plugins and custom code, a new version is out! Even with great tools, the process for about 10% of my network is a nightmare.
While I appreciate the work, it's not very satisfying and for many clients very frustrating to pay for something they know nothing about, just to "keep the lights on".
Is it really that bad to use older version of PHP for longer?
The plugin/theme developers usually develop with older versions of PHP in mind, lot's of plugins still work even with 5.x versions...
For my WP sites I just stick with "two major versions behind" workflow and I don't encounter many problems.
Am I doing it wrong?
In general yes, because of security support.
Moving from 7.4 -> 8.2 will be just as much refactoring as moving from 7.4->8.0->8.1->8.2. Security support is in general three years [0] so everything 7.X is now unsupported. Considering the security cadence you can skip one version, but if you skip two you'll probably be out of security support before you migrate to a new version. My philosophy is if you're going to need to do the work to upgrade anyway, you might as well do smaller chunks more frequently and be able to take advantage of the language goodies that come out earlier.
The amount of the language that gets deprecated every year is PHP's fundamental flaw, at least in the last five years.
But you don't really need to care about upstream security support. Linux distros offer long-term support for specific versions they decided to freeze on, and there are well-known third-party repositories (sury, remi, cloudlinux) that offer even older versions with backported security fixes.
GP's problem seems to be that they have to support WordPress plugins and themes that they either can't or don't want to patch by themselves. This is a different situation from people who build & maintain in-house apps. In that case, always using the previous Ubuntu LTS is a perfectly viable solution. Stay 2-3 years behind the edge, giving enough time for the plugins and themes to get updated, while still receiving security patches and comfortably within the recommended range for WordPress Core.
It depends on your philosophy and your server setup. While my agency/host is proactive, most of my clients were running 7.4 up until a few months ago. 8.o was released two years ago, so you could argue we were/are already employing this strategy.
Eventually you have to upgrade. Do you want to go from 5.6 to 8.2 and possibly have to start over? Or do you want to go version by version, paying smaller amounts more frequently to stay current?
Also: WordPress + Themes + Plugins works best when you don't delay maintenance/upgrades. Everything needs to work in concert. You might be able to freeze your theme in time, but your plugins and the WP core will march on.
The biggest issue is generally server support. Finding servers that support older versions or even package managers that still have the older unsupported versions can be miserable. Thankfully the Sury packages are still around as an alternative, but that's only valid if you're running a system you have full control over (ie a VPS).
A lot of cPanel or similar hosts are also retiring old versions as they hit EOL [1][2][3][4][5] (those all support 7.4 still but most have indicated that will be dropped next year as well). This has made hosting transfers more and more difficult if you don't want to go through the process of upgrading.
The process of upgrading Wordpress sites isn't so bad (generally there's no work, honestly). But not all CMSs are that simple and it can get more laborious when you want to upgrade a Laravel or Symfony site, especially if you've skipped a few versions.
Of course, at the end of the day, it's up to the client to provide budget for these things and if they don't/can't, you just have to push back on their other requests until they do.
1: https://in.godaddy.com/help/retiring-old-php-versions-41164 2: https://www.bluehost.com/hosting/help/php-version-selection-... 3: https://help.dreamhost.com/hc/en-us/articles/215082337-What-... 4: https://wpengine.com/support/php-guide/ 5: https://getflywheel.com/wordpress-support/php-on-flywheel/#p...
You are doing it right.
7.4 just ended its security support so you might argue that you should be at least on 8.0 just in case a bug is found and not backported.
Truth is: it's not likely.
But in any case theres no need whatsoever to use the latest version and even less when you are using WordPress which is notoriously bad at keeping up with PHP releases.
When I tried updating my network of 200+ WordPress websites to 8.0, more than 40 websites broke directly. It's a bit better on 8.1 but in no way is WordPress ready for 8.x at this point.
PHP 8 is in "beta support" currently, but that's just Core. A lot of plugin developers are lightyears behind it seems:
https://make.wordpress.org/core/handbook/references/php-comp...
> It's a bit better on 8.1 but in no way is WordPress ready for 8.x at this point.
WP Core is absolutely compatible. Its the themes, plugins and custom code (usually in functions.php) that isn't.
I actually said that! A base install runs fine on 8.1, but plugin developers are lightyears behind it seems.
> but that's just Core. A lot of plugin developers are lightyears behind it seems.
PHP 8.x vs 5.x is an order of magnitude performance increase [0] as long as you enable jit and opcache in php8 [1]
[0]https://www.cloudways.com/blog/wordpress-performance-on-php-...
The person who says yes is wrong. 2 versions behind would still be able to get security updates so would be perfectly ok for production. 7.4 just went EOL with no security updates. This means 8.0, 8.1, and 8.2 are all receving security updates. 2 behind means you would be on 8.0 and ok.
I think we need a LTS (long term support) version of PHP. One of the great things about it was the non-breaking upgrades for so many years. I mean no version of php7 is supported?
https://www.php.net/supported-versions.php
I know the web needs constant maintenance, but I wish it wasn't so much. PHP has been pretty good about not breaking changes, but I've noticed a few..
PHP is my goto. Its pretty great. It enabled a startup I was part of to get off the ground.
Distributions like Debian maintain their own LTS versions of PHP for many more years than the PHP people themselves, backporting applicable security fixes as necessary.
I run a lot of WP sites on Debian for exactly this reason. Every now and then there's a feature that's unavailable though because someone's written something (usually in a plugin) for a bleeding edge version of PHP.
I think official LTS for PHP would still help, if only to drive a few of the larger developers to target those versions to ensure maximum ease of deployment and maintenance.
Older versions of PHP are supported with security fixes for a while. There's no need to upgrade to 8.2 right now, at all.
Sadly, there is, kind of.
Shared webhosters (speaking for Germany) have started to disable support for PHP 7.x as there are no security patches anymore.
That made it necessary to upgrade lots of WordPress pages, especially older ones had some quirks in themes that broke with PHP 8.
I've updated around 25 sites for an old friend (she's more into the design/content part, not the dev part) and made good money with that. "Stupid" work nevertheless, would've preferred to do something better than run a PHP 8 linter and see where it breaks...
Using a shared hosting provider is a choice you're making there though. If you know you're going to be managing legacy codebases for a while you're far better off spinning up your own box on cloudlinux, which has PHP security patches going back to the early 5.x releases.
It's unreasonable to expect standard hosting providers to cater to those kinds of needs IMO.
Well, yeah, but if you're a two person design agency, which builds WordPress sites on top of $popularTheme in a pair with $Pagebuilder... You don't care that much about controlling your hosting environment...
But I get your point. :-)
> I've updated around 25 sites for an old friend (she's more into the design/content part, not the dev part) and made good money with that. "Stupid" work nevertheless, would've preferred to do something better than run a PHP 8 linter and see where it breaks
Exactly. It's work for our engineers but not something to get excited about. Plus you need to explain to the client why they're paying $1000 for something called "PHP" which they have no concept of.
> It's work for our engineers but not something to get excited about.
Totally not, yeah!
My friend also was surprised/shocked that there were changes in the code necessary to keep those old sites up and running.
Next thing was installing and setting up the "OMGF" plugin to cache Google fonts for GDPR compliance. Stupid work, but quite a few billable hours.
I think the WordPress ecosystem really is... "struggling" (lack of a better word) with how the modern web and the world around it evolves.
The 7 series is 'done' with security updates as of now. https://www.php.net/supported-versions.php
So there's some argument to be made to be in the 8.x series. It's probably not something you should be losing sleep over just yet, but at least have it on your roadmap to address in the coming months.
There are nice improvements that make it worth it to upgrade, but yeah, and you can also just use a Linux distribution that provides support for older versions of PHP (such as Debian stable or the Sury packages).
We upgrade our clients in waves, so sites in dev get the latest PHP, which lets up contribute to upstream PHP projects to fix issues, and by the time it's merged upstream, we can update our older clients without any worries.
You're doing something wrong. WordPress isn't PHP 8 ready yet. Keep that stuff running on 7.4 and you will have had no problems. Plugins and themes don't move as fast..
Also not a PHP problem but a WordPress problem. It's not a healthy eco-system.
WP is PHP 8 ready, but plugins aren't. Some hosts are dropping PHP 7.4 support in January, I know it's causing problems for those who haven't done good maintenance deals.
> Some hosts are dropping PHP 7.4 support in January
Ding ding ding! This guys WordPresses. Even outside my network which is in decent shape, I have clients scrambling because they've ignored PHP updates for 2+ years. Sometimes burying your head in the sand is not the best strategy.
Also some themes or theme builders aren't compatible too.
Correct. Every decent theme and plugin publishes a handful of updates every year. Locking your WP site "in time" is not a viable option. If that's your strategy, just build a static HTML site.
Theme and plugin updates keep rolling in.. I'm only locking the PHP version until all themes and plugins the site uses are compatible with 8.
A hosting provider that forces people to PHP 8 is not a good hosting platform for WordPress.
> It's not a healthy eco-system.
I'd argue that's true for all of PHP. Sure it got better, but compared to other langugaes it is still a mess.
None of this is on PHP the language. The roadmap is extremely clear for PHP. The problem is the likes of Wordpress having no oversight on their plugin directory. Really they should've stopped accepting new listings / updates for plugins that dont support the latest release.
Wordpress has a lot to answer for here, but given the archaic and frankly idiotic way they operate they'll do nothing of the sort.
PHP is very backwards friendly and with a strong and stable ecosystem built around composer theres no excuses for majorly used (and often very profitable) wordpress plugins lagging so far behind.
Disagree, composer exists, namespaces exist, autoloading exists. Enough quality frameworks.
I hope you can give some factual arguments why it's still a mess.
I think GP was not talking about PHP ecosystem in general but about Wordpress ecosystem in particular. And I largely support this claim.
Please provide arguments to support your claim.
Similar boat for me, I manage a few hundred Drupal sites and I spend a lot of my time on Drupal updates and PHP updates. Just finished the upgrade to PHP 8.1, and now I know the start of my year will be PHP 8.2 and Drupal 10 upgrades.
I still have an anxiety response just seeing the word Drupal.
I feel your pain cousin Drupal!
Don’t worry WordPress doesn’t support 8.2
How do you mean? The meta ticket (https://core.trac.wordpress.org/ticket/56009#comment:27) is pretty clear that all unit tests are passing, the only issues left being deprecation notices, not errors. Have you tried it and found the core failed somewhere?
Yeah I wish the focus was more on backwards compatibility at this point. Most PHP codebases are very old.
I hope you charge for it.
That said there are languages where very little backward incompatible changes are made. Java comes to mind.
Also: putting each client in a sandbox (VM, VPS, etc) can help you to keep some clients on the old versions, and/or do PHP interpreter migrations on your own timeline.
> I hope you charge for it.
I do and appreciate the job security but I respect my clients (small biz owners) and it's just not satisfying and for the 10% that have issues, costly.
Don't update php and freeze the files and the database so they can't be hacked.
Sure, but what stops them from modifying the database?
> Java comes to mind.
Java used to be like that, but the migration to the module system has been very rocky for me personally when revisiting older projects.
Does Wordpress require the latest version of PHP? Is there not an LTS?
Let me put it this way: there are major plugins with millions of installs that do not support PHP 8.0.
I even host a few installs on the latest 7.x version.
I don't understand where this update hysteria comes from. PHP 8.1 security support ends in Nov 2024.
Everyone lags behind but the pace in the last 2 years has quickened. Even if you lag (post 5x years), eventually you have to match the cadence.
Well, essentially you are getting paid because of that. So if it all went smoothly you'd be out of a job.
This work represented about 1-2% of our revenue this past year. While not insignificant, we'd certainly have plenty of work even if these upgrades went perfectly.
Why do you feel compelled to update to every point release?
How do you deal with Nginx/Apache updates given they release more frequently than PHP?
You can always host at a managed hosting provider who will take care of this for you.
> Why do you feel compelled to update to every point release?
I don't. We just finished upgrades from 7.4 to 8.0. PHP 8 was release November 26, 2020 - two years ago!
> How do you deal with Nginx/Apache updates given they release more frequently than PHP?
My managed host deals with that.
> You can always host at a managed hosting provider who will take care of this for you.
I have a "managed" host and none of them will make your code compatible. It requires a software engineer and lots of unglamorous work.
> and lots of unglamorous work.
This.
The PHP developers are trying to turn PHP into a decent, fairly modern language. This has involved quite a lot of breaking changes in the last few years, and upgrading website code just so it works with the latest version (i.e. no actual improvements) isn't appealing work.
> How do you deal with Nginx/Apache updates given they release more frequently than PHP?
Can't speak for Nginx, but Apache updates very rarely screw with syntax, and those are always major releases. And for Apache, "syntax" just means config files.
PHP screws with syntax frequently, and often on point releases. And PHP is a programming language; syntax is the whole point of PHP.
As someone who has written in past a lot of PHP and Python, I find it interesting that PHP devs can do a lot of breaking changes, and don't get a huge amount of flak for it.
Python 2 -> 3 change really was painful for Python community, but PHP does these almost fundamental breaking changes so often, that maybe people just get used to it? I haven't really followed Python past version 2, but I think they are less likely to ever do such amount of breaking changes.
There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc. Someone must be pulling a lot of hairs because of this.
Edit: Those dogpiling there, I rest my case with josefresco's comment:
https://news.ycombinator.com/item?id=33907628
It's painful. Dropping dynamic properties? That will be a lot of fun. WordPress is probably biggest segment for PHP usage.
> PHP does these almost fundamental breaking changes so often, that maybe people just get used to it?
PHP also cares a great deal about backwards compatibility. There are long deprecation phases before anything gets removed.
The RFC system also helps a lot in ensuring that changes to the language are well thought out to and discussed beforehand. The is not much change just for change's sake. Churn is kept to a minimal while still allowing the language to evolve.
> There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc. Someone must be pulling a lot of hairs because of this.
PHP upgrades are also good money for agencies. Got to earn that bread.
And to let out a dirty secret, for really hopeless projects there is the option to keep them on life-support by running them inside a docker container with an older PHP version. (Horrible but if that's what the customer wants, it's their risk.)
PHP learned the lessons of the Python 2/3 transition and is making backwards compatibility breaks much more carefully. “fundamental breaking changes […] often” seems like an exaggeration to me.
PHP 7 made a few big and necessary changes but they generally did not affect well-written code much. Python 3 broke a lot of things without good justifications, and without a way to make your code compatible with Python 2 at the same time.
I remember one breaking syntax change in PHP 7 a larger project was affected and it was tested with grep and fixed with sed in a matter of minutes.
There is benefit if you have the project under test and can run the build with different php versions thought. Best in parallel so you have current, next and future. It perhaps becomes the norm since the yearly release cycle but always was a requirement when supporting different php versions.
Can you give some specific examples? I can't think of too many 'fundamental breaking changes' in PHP between major versions. Some things that will be changed in 9 are now deprecated in 8.2.
PHP has gone through a few changes.
PHP 3->4 was a moderately big change under the hood, and introduced a lot of new things, but most 3 'worked' under 4 (but was... awkward).
PHP 4->5 - a few 'big' things changed - XML processing changed - I had to use some shims to get some projects upgraded.
PHP 5->7 - my recollection, and that of most colleagues, is that this was pretty painless for most projects. I can't recall too many major breaking changes, but it was mostly just getting a doubling of speed without any substantive changes.
The PHP community has a couple decades of 'major version changes' to look at to learn from. I still can't say I agree with 100% of the decisions, but it's still progressing nicely.
Php 7 -> Php 8 is where php has really started making more breaking changes (for better or worse). Or at least introduced lots of new warnings.
Deprecation warnings for the most. But those can be taken away so you can have PHP 5/7/8 code without much deviation.
More than a LTS release I'd prefer more PHP 8 releases than the five in 7.x, e.g. more until 8.8 or 8.9.
> PHP 5->7 - my recollection, and that of most colleagues, is that this was pretty painless for most projects.
They replaced the MySQL plugin in version 7. All MySQL code was broken. I don't know, but I'd guess that most PHP sites were using MySQL as their database (the 'M' in 'LAMP' stands for MySQL).
Using mysql_ functions directly was very outdated and long deprecated when 7 was released. Any reasonably maintained code base had already been using mysqli or PDO for years.
I thought I had to replace all my mysql code in a massive overhaul to upgrade from 5.x to 7.x.
Then I read a little closer, and realized I pretty much just had to add an "i" onto all the underlying mysql functions ("mysql_" to "mysqli_"), at least for the ones I was using commonly.
I'm still in the process of migrating that project, now on 7.4, to a modern Symfony framework, but I tested it out in 8.1 the other day, and it needed...1 change to work apparently perfectly.
I'm still going to need to do more thorough testing before I put production on 8.x, but with 7.x now unsupported, that has become a priority.
IIRC the parameter order for some parameters differs between mysql_* and mysqli_* functions. But as someone else said above, built-in PDO or some other abstraction library for data access has been the way to go for more than a decade (more like closer to 20 years at least).
That said, I'm still surprised when I come in to codebases where people are still using hard-coded db function calls all over the place (mysql_* or mysqli_) I indicate that abstracting that away should be a priority. Even doing something as simple as "I want to log all the queries that I'm making for debug purposes" is essentially impossible when you have hundreds of individual calls to mysql_ embedded throughout the code. But... I've not come in to a codebase in the last... 4-5 years that does that, so either I've been lucky or that coding behavior is indeed becoming a thing of the past.
Yyyyep. That's a big part of the migration I've been working on. However, it's a non-monetized side project that I inherited with a loooot of legacy code, so it's not exactly going to be speedy.
> All MySQL code was broken.
Not quite. Code that *wasn't* using either of the two modern APIs for MySQL was "broken".
They removed the oldest, jankiest of the three APIs for connecting to MySQL in php7.
MySQLi (literally, "MySQL Improved" extension) was introduced with PHP 5.0, in 2004.
PDO was introduced with PHP 5.1 in 2005.
The documentation started showing "soft deprecation" notices on mysql_* functions in 2012. It was already common practice to advise people to upgrade to either mysqli or PDO.
The old mysql extension was deprecated as of php5.5, in 2013.
The final shipped version with the mysql extension was 5.6, which was supported until 2018 - half a decade after the deprecation was added.
I actually found Python as an organisation quite obnoxious during the transition to 3.
Even as someone who supported it. Perhaps there was internal built up resentment.
Whatever it was it showed in their communication.
Very occasionally I have to communicate on a topic I think could see backlash based on internal views. I make an effort to communicate it as neurally as possible.
My org currently prefers a saccharin approach when there is controversy I can't stand that, but I prefer it to over the like it or lump it bristling with rage approach Python took.
Tons of them. If PHP really powers 50% of the internet, as they say, then maybe 25% of the internet is running an out-of-date PHP version. Then get into out of date Wordpress installs (can't risk breaking that plugin) and Magento 1 installs (out of support for half a decade, still in widespread use) and remember that they can't even update PHP without updating the Framework. In general, Laravel is sometimes better if the devs have been upgrading every LTS or so, that's once every two years. But if they miss an LTS, Laravel installs fall just as fall behind as any other framework.> There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc.
No, nobody really cares. Sometimes I'm paid a lot of money to fix things, though, so I'm not bothered by the situation either. It seems that once a site is passed to the content managers, the only way to budget for upgrading the site is when there is a problem. Never mind that they might have some small internal dev team adding features all this time.> Someone must be pulling a lot of hairs because of this.> but PHP does these almost fundamental breaking changes so often
I have a private (non-internet) web-app that's still on PHP6.5; I like the new PHP features, but upgrading private code to conform to PHP 7 and 8 looks a lot like make-work. I wish it shipped with good upgrade tools.
[Edit] @darkwater (below) is correct; I meant PHP 5.6. PHP6 was some kind of abortion - I can't remember the story.
> but upgrading private code to conform to PHP 7 and 8 looks a lot like make-work. I wish it shipped with good upgrade tools.
I'm doing this quite often as I maintain some code-bases that have backward compat down to PHP 5.3 as the baseline. So if you're looking for forward compatibility of your PHP 5.6 codebase to 7.x and 8.x (incl. 8.2), its not so much of work.
If you need an upgrade tool, have different PHP versions at hand and load each file on the CLI and PHP will show you the deprecation warnings. It then depends a bit on the code (each()/next()/reset() family undergone some changes if not removals in 8? so you have to replace with some different syntax) but most of the rest is only deprecation warnings that can be overcome with #attributes "annotations" that are just comments prior php 8.
tooling could be better especially if you're running from low versions, thought. but using php on the cli directly brings you quite far and on speed already for most things in my personal experience. git, find and xargs are your friends.
>PHP6 was some kind of abortion
IIRC, the initial development was in the mid 2000s but it was abandoned several years later because they couldn't get Unicode support working correctly. By the time it was abandoned there was already a lot of material referencing it like books and conference talks. So when the PHP team decided to do a new major version most of the planned PHP 6 features were already added to 5.3 and 5.4 so they thought it best to just skip 6 to avoid confusion.
> PHP6.5
Is that a joke? PHP 6 doesn't exist...
They probably meant 5.6
The big difference is that while the PHP major upgrades - although had breaking changes - provided a forward-compatible way for you to run older version code on a newer version PHP (see WordPress for PHP 5 running fine on PHP 8), Python did not offer such a thing; code was either exclusively for Python 2 or for Python 3, making upgrade paths very difficult.
Python was invented and heavily used before most people could even access the web, nevermind building dynamic websites. The web has always been churning heavily--HTML, browsers, JS, etc. changing and adding features etc. Web folks have always been dealing with churn. In contrast some people have scripted out tons of python code for managing computers, labs, etc. and they absolutely cannot and will not tolerate churn or things breaking with minor python releases.
I don't think PHP's introduced anything quite as disruptive, for example, as introducing bytes vs strings. Where no tool can really convert existing code.
Well there once was such an idea. That what would have become PHP 6. But then there was the decision to not do that, keep strings binary only and never release PHP 6. Instead we had seen a couple more PHP 5.x releases and the yearly release cycle was introduced (with 5.6 having extended community support [plus one more year]).
if your project is managed by composer you just set your compatible php version and you’re set. the 5.6 to 7 conversion was painless for most because 7 was largely backwards incompatible. I did it for a 300kloc 10 year old codebase in a few days. After that the breaking changes have been pretty easy to manage, and many users are still on 7.4. 8 is where things have really started to change but still the process is not that hard.
but this isn't the case for PHP at all? The PHP side of upgrades are, usually, trivially simple and you are given literal years of deprecation warnings before anything happens. The tricky part (as always in PHP) is the modules and stuff, but that is getting better
PHP doesn't do a lot of BC-break. Proposing one and getting it accepted is very difficult (2/3 of +1 votes required). Most cases of BC breaks are based on security concerns.
PHP didn't learn from Python 3 BC fiasco, its governance makes such changes very difficult to be made.
I write PHP every day and I don't mind the language at all. It's not exciting per-say, but it's a good tool for the job. My real complaint is about how it's served via Apache and my real problem there is that Apache just depends on a lot of things being in the right place and it can suck for updates since it's harder to keep all things config in your repo. Docker is probably a fix for that, but there's an internal political battle there that I'd rather not touch.
I know this is contradictory to what some people love about PHP, but having a directory where everything is isolated and I just run npm start or my go binary or whatever is much easier to reason about for me, rather than also have to think about Apache's end.
Why not nginx with php-fpm?
That won't really solve having config files at different places though.
I also write PHP every day, and the solution I've landed in is, as you suggest, Docker. With Docker and docker-compose you can put Apache config, MySQL data, etc, in your working directory which makes moving/backing up your project a lot easier.
There is however a significant overhead to Docker. Building images takes time (and you will need to build your own, if you rely on any kind of PHP extension such as mbstring, etc) and just wrapping your head around everything is harder than people make it out to be.
That being said, I used to have my own set of bash scripts to setup local virtual hosts, databases, etc, and various strategies to keep configuration contained to single projects, but things always leaked out of the boxes I tried to put it in and in the end all those strategies failed.
So, my current estimate is that Docker doesn't save me much time, but it elevates the quality of the projects I'm working on. So overall I find it worth it to put in the effort to use Docker.
Caddy works quite nicely in front of php-fpm, as a replacement for apache.
Apache doesn’t need to be in the loop. You can run php-fpm directly behind a load balancer that supports fastcgi, like haproxy. And for depvelopment you can simply use the built in server.
Most serious web apps will end up behind a reverse proxy with nginx or apache though
I haven't used PHP in almost a decade, but I've been super impressed with what I've seen in the most recent few versions. Looks really cool, it's gotten me tempted to dust it off again at some point
I've been working professionally with PHP for the last decade or so, and the last few years have been so good. The changes are very welcomed, and the performance improvements are amazing in general.
The codebases that you can create nowadays are light years away from what you would see 10 years ago. And the frameworks have improved alongside too.
It has been a decade for me too, if not more. What's your favorite framework/tools/tips? I'd love to get back into it.
Pick one framework between Symfony and Laravel and follow the docs.
Maybe read https://stitcher.io posts about the new features since 8.0 to have a grasp of the language changes.
What would you recommend? Looking for a more robust and streamlined solution to build small(er) pages...
Not OP but I'd personally recommend Laravel over Symfony if you're just getting back into it. Fundimentally they are very similar, but Laravel's less of a learning curve and these days has a significantly larger community.
There's resources like laracasts which take you through from the basics to highly complex concepts without it feeling like you're being lectured.
One benefit of Laravel is that under the hood it shares a lot of Symfonys core components so should you decide to switch at some point it's not too much of a learning curve.
Thanks, I guess I'll look into Laravel then.
If it helps, Laravel feels like the Rails of the PHP community.
I've used it to build ~5 websites and it's been very solid. The docs are pretty good and it does most of what you need out of the box. Especially the 8+ versions of Laravel. If there's something you need that's not included in the framework itself, it's likely there's a well-maintained community package.
Just my 2c.
Thank you, that helped me. Had a quick glance at the documentation and it seemed solid indeed.
Same. The vibe difference between a modern php app and an old php app is so tangible, it makes you constantly appreciate it.
Do yourself an extra favour and start with Symfony or Laravel. These frameworks are a joy to work with.
We picked Laravel ~15 years ago, and regret it.
For getting up and running, it saves time. For large projects, it adds leaky abstractions, overhead for each request, a need to upgrade another layer - with poor upgrade compatibility (in our anecdotal case), and very little gain. And it has it's own learning curve, which with modern PHP may be redundant.
Symfony looks better in that it is more of a library and less of a framework, though of course that has its own tradeoffs.
IMO, the weakest part of PHP is the db functions (both PDO and mysqli/postgres)
The fact that the language is weirdly executed server side is a non starter imo. PHP is still the only language doing that no?
Edit: I'm talking about the php code being compiled / run by an external process which makes the whole thing staless.
It was a "working" design when people were dropping .php files in ftp folder on some hosting provider.
What is weird?
That it's stateless, and therefore often deployed with a module or FPM?
You're not making any sense with this sentence or explanation, why even comment if you're unaware of the execution model?
What "external" process are you talking about?
Why do you need mod_php, php-fpm, zend etc ... to create a PHP "server"?
This model is imo outdated, why can't we create a PHP server that just runs without the need of something external.
mod_php: to embed PHP binary into Apache process. It's related to Apache, not PHP.
PHP-FPM is the server you're talking about. It's a supervisor process that forks into N child processes, each handling incoming request. Supervisor deals with child exits and respawns, keeping the whole thing alive and robust.
This model is what PM2 does for node.js to keep it alive when it crashes.
There's also PHP command line interface that lets you run a server by starting a PHP script, in which you get to access OS's event loop and various other lower level interfaces.
You don't seem to be knowledgeable about the topic and you're assuming something entirely wrong. Why didn't you google before this discussion?
One can start a synchronous, process-based server or event-loop async one. What exactly is outdated here and how does ANY other language do it differently?
I went and it came out even more confusing, with things like SAPI. It seems that there are many different way of running a simple REST API server in PHP. Where is the code running, what's compiling it / caching it etc ...
The dialogue makes no sense if you're convinced in one thing and refuse to participate in understanding that your assumption is wrong.
All servers, of any kind, work the same way. Whether you want to accept it or not is not up to me, but fact remains.
PHP does not work in any different way, but it seems there's this huge barrier where you want to believe you're right. I can't dispel that so I bid you farewell.
What does "weirdly executed" mean? I can't even guess so would you be so kind to clarify?
You can run it standalone. On the command line: "php myscript.php"
Not as big a leap compared to 8.1 since Nikita left full-time development, but still a good trend. Lots of good changes to types (removing dynamic properties by default, redacted properties, readonly classes, more complex types etc).
This is the post I came looking for! Disappointed but not surprised I had to wade through all the usual comments about "fractal of bad design" and "actually, PHP is great" to find someone actually talking about the new features.
The SensitiveParameter attribute is a really nice addition that isn't highlighted on the release page.
I think PHP is getting better but... For any greenfield project, I'll not pick it.
Also, I'll not pick any of the interpreted languages for that matter and would want Golang/Crystal/Nim to get single binary to be packaged.
But of course - this isn't necessarily something everyone would do.
There are no right or wrong answers here I suppose.
Curious, what kind greenfield projects do you work on?
Web or something else?
I ask because I haven't heard many using Crystal/Nim for web.
I need to use PHP at work sometimes. After working in it for a while I still don't love the language and would never pick it for a project myself, but it's overall decent a few quirks aside, and I think a lot of people have built up a habit of disparaging it without actually knowing much about it.
That being said, one issue I've found is that while I can use VSCode for every other language, using PHP feels terrible if I'm not using a JetBrains IDE. I tried installing the PHP extension pack, but it was still leagues behind. Is there any guide someone can recommend for making PHP a first-class language in VSCode, or am I stuck in phpStorm?
> I think a lot of people have built up a habit of disparaging it without actually knowing much about it.
It's possible that PHP's ubiquity and the core language's poor architecture/design (for decades now) are the source, not the ignorance of those complaining. PHP was the very first programming language I learned, in 1997. If anything, I mostly stopped disparaging it because I simply moved on in my career enough to be able to choose languages that aren't constantly fighting me.
I'm a consultant so I get asked about unfucking PHP codebases every few years, and I check in on the ecosystem and language. It's better but (unsurprisingly) still not great. Meanwhile, languages a decade+ younger avoided PHP's mistakes.
PHP 8.2.0 changelog - https://www.php.net/ChangeLog-8.php#8.2.0
PHP supported versions - https://www.php.net/supported-versions.php
Many are praising the recent releases of PHP for their quality and performance improvements, and I wouldn't dare argue against that. However, the current release schedule of PHP makes things a little bit difficult for sysadmins. We're now using php-fpm docker containers so that we can (sort-of almost) keep up with PHP updates without doing OS upgrades every single year. A LTS version would be welcome!
PHP 8.2 will get official security updates until December 8, 2025, how much longer do you need?
Well, try working on enterprise and you know how much long support they need. Move fast and break things simply doesn't work and doesn't scale properly.
I see 5 years as a good minimum for LTS. Perhaps it's a personal bias, since our OS of choice (Debian) offers LTS for 5 years.
Edit for context: the small business that I work for takes on all kinds of random web work. It's not uncommon at all for us to be asked to rescue an application or website that's still running on PHP 5. For projects that we have initiated, by the time we migrate them all to PHP 8.2, it will be End of Life.
Thats just 3 years, and likely the next release will be again full of incompatible changes. That's not a long timeframe for all but the most active (or smallest) codebases.
It's not the same, but MySQL offers like 8 years https://endoflife.software/applications/databases/mysql. Obviously very different software with different goals and monetization models (none vs some). Not apples to apples but figured it was a good example of what someone might have in mind.
PHP 7, released December 2015, 7 years ago, still gets bug and security patches. Seems similar to me.
It doesn't though (granted, support for PHP 7.4 only ended 10 days ago, so you can be forgiven for not knowing): https://www.php.net/supported-versions.php
But PHP 7.4 is not compatible in many ways with PHP 7.3, so lumping them together is not OK. As you can see, PHP 8.0 which was only released two years ago, is no longer receiving active support. Definitely, database LTS is not comparable to programming languages. However such rapid releases of breaking versions is a relatively new phenomenon (thanks NodeJS), and I get the feeling that you've never actually supported a software project for 5+ years.
A decade would be nice.
If you're using a Debian based OS, Ondřej Surý runs a Debian and Ubuntu compatible repos for up-to-date PHP releases. He's also on the PHP packaging team for Debian proper, so these are basically the updated packages that will end up in Debian stable eventually, but available for the most recent few versions.
What's the difficulty for sysadmins? Maybe it's particular to your OS? With FreeBSD for example, there are port flavours for the various PHP versions, and it easy to choose.
Debian historically does not maintain multiple versions of PHP in official channels. Your options are:
1. Compile PHP yourself (no)
2. Use an untrusted third party repo (probably not)
3. Upgrade OS to latest
4. (apparently) Use FreeBSD instead.
For all I know this could change. The current release schedule of PHP is greatly accelerated from what it was 5-10 years ago, and we're all still adjusting I think.
> Use an untrusted third party repo
If you can't trust Ondřej Surý's repo, you're gonna be disappointed when you see who maintains the PHP packages in Debian's official repo.
I never got it why PHP kept getting bashed even nowadays, it's still the No.1 language for server side web building, Wordpress's market share alone eclipses all its "competitors" such as Nodejs and Django and Flask etc combined then times 100.
It's just like the Rust folks never miss any chance to bash C++, while C++'s market share keeps rising and after 16 years since Rust was created, it can not even make 1% of the market while C++ is 12%(excluding C which is 16%,again it keeps rising).
Rust's goal by the way should just replace Ada for specific areas, to take on C++ on a broader level it probably needs another few decades, if it can ever make it that is.
I think it is a mistake to conflate the success of the Wordpress ecosystem (and its plugins) with the success of PHP. Just because Wordpress is popular as a CMS does not mean that the developers of Wordpress plugins would choose PHP otherwise.
It's also not a contest? I'm not sure why people care about these numbers. PHP keeps getting bashed because it's a bad programming language full of footguns, then and now, regardless of whether or not other programming languages exist.
"16 years since Rust was created"?
how is it 16 years when Rust 1.0 was released in 2015?
8.2 is going to be a stopping point for a lot of projects that rely upon older code that has dynamic properties in classes. It's not a particularly hard fix but I imagine it people will quickly end up in fork/private repo hell as people throw explicit properties on old libraries and cross their fingers.
PHP seems better now, but what would be the reason to choose PHP when Go, Rust, and Elixir already exist?
More battle tested, widely used, robust and overall just better frameworks and libraries for Web Dev and a bigger community, also specifically focused on web. That’s my bet.
Apples and oranges. For one, PHP is a scripting language.
Deprecated variables in strings? Or just when using the curly braces syntax for some reason? Unlike with every other entry there's no link but this sounds like the biggest change since PHP 4. Anyone know where to find more info?
PHP string interpolation has 3 possible syntaxes: $var, {$var} and ${var}. The last one is now deprecated. I've never seen it used in the wild, and it has some odd limitations. It's discussed in the RFC[1].
[1]: https://wiki.php.net/rfc/deprecate_dollar_brace_string_inter...
Seems strange to remove it when Javascript has introduced it with backtick strings like:
`words ${var} more words`
I thought we would start seeing more usage of this in PHP to make things more consistent.
The ${var} syntax is inconsistent with PHP’s own syntax though. Variables are normally referenced with a leading dollar sign, like $var, so if you wanted to make it look like template strings in JS it’d be ${$var} which is over complicated.
>I've never seen it used in the wild
I imagine it might crop up for people that also use Perl, since that would be more common there, like:
$foo="abc${var}def";
bash also uses the same syntax, and I've probably used it before for that reason.
Interesting that one developer voted no (out of 32 developers in total). Wonder what the reasoning was? Seems like a change with small impact and reduced amount of code to maintain, so not lots of drawbacks.
Only this specific curly braces syntax, which is less powerful than the still-supported '{$foo}' variant: https://wiki.php.net/rfc/deprecate_dollar_brace_string_inter...
Ah, okay that's a much smaller change then. Thanks for the info and link!
Kinda odd that Bash has had this syntax since forever, Perl as well, JavaScript went out of its way to add it as well, and now php is like: let's remove this syntax specifically but allow typo variants of it!
Oh well. Not like I was using it, that is, I use the bare "$foo" syntax and try not to make string interpolation too complicated with inline expressions or some such. Just, I could have seen the logic behind switching to the more universally supported syntax and deprecating something else rather than doing their one-off thing.
In bash/shell the expression $a is "just" a shorthand for ${a}, which is the more general syntax. Shell does not really make a distinction between string interpolation and ... well, everything else. It's a bit like how we don't always have to write out the curly braces of an if statement in C.
I'll also point out that in shell assignment looks like
nota="foo"
The dollar sign of shell feels to me more like an operator you use when you want to access the value of a variable. Not a part of the name of the variable as in PHP.$a="foo"
There is an error in the examples on this release page about traits with constants, it says that
return self::CONSTANT; // Fatal error
however that is actually allowed, what is an fatal error is
return Foo::CONSTANT; // Fatal error
compare
https://3v4l.org/dIeOk#v8.2rc7
https://3v4l.org/11of1#v8.2rc7
Prohibit direct access through a trait name
What's the standard way to install php, by using `brew install php` ? Is there a version manager for php itself to have multiple versions of php in the system ?
If you're doing development across multiple versions and you don't already have a system, start with `asdf`.
ASDF has php plugin so you can install multiple versions of php, python, nodejs, etc in your machine without conflicts.
I don't believe there's a specific way to install or manage it. Use the facilities your host OS provides just as you'd do with Ruby, Python or Perl.
As per how to select versions easily, the Symfony project provides a Symfony CLI and one of the features it provides is checking for a `.php-version` file in the current directory and selecting the correct php binary from the PATH accordingly.
I use that when I'm dealing with projects on different versions.
> Use the facilities your host OS provides just as you'd do with Ruby, Python or Perl.
Well that's the thing: I don't know anyone who actively develops in Ruby, Python, Perl or Node that uses the OS-packaged runtimes. The system packages and the language-specific package managers live in different universes.
I've seen this situation blamed on both OS packagers or language ecosystems, but now I just think the goals between the two just are fundamentally at odds.
> I've seen this situation blamed on both OS packagers or language ecosystems, but now I just think the goals between the two just are fundamentally at odds.
I hate language-specific package managers. I can see their value to packagers (less work), but they end up arguing with the platform package manager.
It's like there's a load of CS graduates churning out lots of new, better languages; but what's really needed is just one better language. Similarly we have a score of new package managers, creating incompatibilities; so we add some more package managers, to paper over the incompatibilities.
I'm inclined to the view that perhaps there are too many coders in the world, creating compilers and package managers because they can't get a job doing something useful.
https://www.reddit.com/r/linux/comments/nnxng/petition_lenna...
> I'm inclined to the view that perhaps there are too many coders in the world, creating compilers and package managers because they can't get a job doing something useful.
I truly hope that this outlook on the world does you better than it did me when I was younger.
Since PHP is typically invoked as a web server module or SAPI, you can install as many versions as you want and which one you use comes down to the version you've configured in your web server.
You _can_ use PHP from the command line but it's not the same kind of thing as Python or other languages where you need to be mindful of which version some shell script might assume is installed, etc..
I use the systems' package manager to install php on my system and it supports having multiple php versions.
That is for all but one version that is compiled from sources.
What’s a feature that PHP is missing, that if it had it - would garner it more respect?
Note: I think PHP is way under appreciated.
Hmmm, how do I say this without being downvoted... it's not as much a feature that is missing, it's unfortunately the whole origin of PHP as a language that wasn't really carefully designed, but just kinda grew organically (famously Rasmus Lerdorf didn't intend it to be a general purpose programming language at all, but "just" a templating language). Despite the efforts since PHP 7 (also partly already PHP 5) to make it more "professional", it won't be possible to completely shake off this legacy. Don't get me wrong, I like PHP as a no-nonsense language in which you can get web dev tasks done quickly and effectively, and I would pick PHP over Node any time, but the inherited warts are undeniable and at least some of them are here to stay.
Which warts?
That I start a code file with a special tag, that I have to be careful not accidently emitting e.g. white space (because it is a template engine ;)), that I am not accidently emitting the source code of my program because a tag was not closed, ...
Like the poster above: I totally support PHP ... it is good, it has surprisingly well aged in the recent years, and it perfectly has its place ... but it has warts. Nothing bad, nothing tooling could not compensate ... but there are warts because of its origin.
Other languages has warts too: Java has no real generics, Python has it when you do indenting wrong and let us not start on JavaScript or god forbid VisualBasic. As a C# fanboy, i have to rely on others to see warts there ;)
Type hinting for arrays and all data structures
They'd gather back my respect when they get rid of all the moronic behavior they have in the functions of their global namespace
* Like sleep that returns 192 on windows but not on linux when you interrupt it
* hash_hmac that if you pass array to $data, php will generate a Warning, return a NULL and continue, I'll let you imagine how bad this is in the context of hmacs when null gets typecast to 0 later on
* etc
The manual doesn't indicate the specific change (this is one area of weakness for the language), but hash_hmac already no longer does what you're talking about: passing a non-string there is a TypeError since 8.0.
Increased strictness in the types that can be passed to the built-in functions has been a general area of focus for the last several versions.
I'd say you are probably down voted because you do not provide argument as to why it is under appreciated.
The thing is that PHP is (was) a good example of bad language design. It's original creator is (was) also known for its total disdain for "correct working software". The language and standard library even more show this quite clearly.
See reddit.com/r/lolphp for a community dedicated to bringing PHP's bad design pearls to the surface.
* function autoloading * typedef * templating hooks for escaping output and such * better phpdoc, e.g define class without creating class, nested structures. * inner class * modules (instead of namespaces)1. Support for generic programming.
2. Officially supported runtime that exposes system event loop to userland (yes, we have swoole and roadrunner)
Related to #2, doesn’t this then make PHP stateful - which some might argue is a negative.
EDIT: have you looked at ngx-php. It’s blazing fast and provides you that event loop.
Stateful as in it would preserve objects/variables between requests (if served by the server that spins the runtime up)?
That's something up for debate. Personally, I'd like the shared-nothing approach but I'd like to have async capabilities to optimize I/O and a function that flushes the request and frees up resources for next request in queue.
edit: I haven't seen ngx_php, thanks for the link!
For me something to stand out in the current day and age. THE "killer" feature.
It has some nice things but for everything in PHP, there other languages that do it a lot better. And I don't think CGI is a killer feature in 2022, it doesn't matter anymore than any other implementation detail, and causes more problems than it solves.
Having an event loop that can freeze your whole application, is my guess.
Isn’t a huge benefit of how PHP executes is that it’s stateless.
In most languages you can choose your execution model. Stateless then is an option, a design choice.
If it's all your language does, I do not think it counts as a benefit. Not in my book at least.
Can you give an example of another language you can do this?
Note: PHP has Swoole, etc.
most interpreted languages cannot without big overhead
Typed collections.
the curious thing with php is that while some very notable and impactful projects are using it (besides wordpress you have things like wikipedia powered by mediawiki, nextcloud, moodle etc) somehow this has not translated into creating much press for the ecosystem as a whole nor a sense that its heading somewhere and carving its own valuable niche
there is symphony/laravel as web frameworks, which by all accounts are modern and highly usable, but that in itself doesn't distinguish php given how many alternatives exist
> nor a sense that its heading somewhere and carving its own valuable niche
The major niche has been carved long ago. Low cost code for budget conscience clients. PHP has long been the easiest on-ramp to webdev for many folks and some of the things out of it Wordpress specifically, can be utilized to cover a vast number of rather low complexity needs. If you consult with budget conscience clients, you likely find PHP indispensable. If you (or your employer) are building your own software product, you care more about DX and such and have chosen something else. In both scenarios, the end users of the product do not give a damn what it was built with.
People still use PHP? Let this horrible language die already. It's banned internally at AMZN for a reason
PHP has been pretty good for a long time now. PHP 7 was released in 2015. It's a vibrant and living language that now has a very nice type system and a super-fast JIT. Most of what people hate about PHP is from PHP 4, even 5.6 was pretty solid. Let this horrible meme that PHP sucks die.
It's not a meme, it's backed by empirical data. It's banned for security reasons internally at AMZN, not without due diligence
Is C banned then too? And the use of npm?
again, there were definitely huge problems with PHP prior to 5.6 and 7, but the flaws in the language that made it a security nightmare have been gone for about 10 years (at least). Now the main problem is that it's still used as a dynamically typed language with some type coercion and juggling that can lead to unexpected behavior.
But you can use strict_types! With strict types, PHP 8+ is a very nice language.
You say it like some internal decision of some unnamed nobody at "AMZN" is some standard of excellence, or whatever.
more like the entirety of the company (Amazon + AWS) following the guidance of an unnamed "nobody" is, in fact, a standard of excellence :)
I challenge you to find PHP deployed in production in any Amazon service
That's irrelevant to anyone not working at Amazon.
I will SSH into amazon and check right now.