Why not PHP?
I was intrigued by Why Not Rust, a list of compelling disadvantages written by someone who uses Rust a lot, and the author of a popular Rust static analysis tool. I have a similar relationship to PHP – I use it every day (at Vimeo), and I’m the author of a popular PHP static analysis tool.
The similarities end there, though – Rust and PHP are very different languages, with very different reputations in the wider programming community. Rust has been getting a lot of hype in the last few years, while PHP has been getting the opposite. Indeed, a lot has been written about PHP from a place of contempt. Here’s my attempt to argue against PHP, but from a place of admiration:
It’s mainly for serving simple HTTP requests
PHP was originally designed for the then-nascent world wide web, and its popularity has risen (and, lately, fallen) with the popularity of server-rendered HTML.
Its process model (no shared memory between requests) makes it ideal for serving HTML on a case-by-case basis. If that’s what you’re after, it’s incredibly easy to get started.
On the one hand that means the average PHP programmer never has to worry about memory-related race conditions within a single request, because they simply can’t happen.
But all of PHP’s optimisations for serving individual HTML requests will get in the way if you do, in fact, want to run your own service with shared memory between requests, or any other long-running process. While PHP can do that, its implementation won’t be half as pretty as it would be in a language like Go.
It’s (relatively) old
New programming languages are often a thoughtful combination of languages that came before them. Writing code in a recently-written language can expose you to new idioms, and helps you see the world of programming through a different lens.
PHP is not a new language – it’s 26 years old, and pretty thoroughly-cooked at this point.
No large corporate backers
Some languages come directly from large profitable companies that devote considerable resources to their development (e.g. Go, TypeScript, C#, Swift, Java, Kotlin) while others are sort of adopted by companies (Python at Dropbox, OCaml at Jane St, JS interpreters at Google & Mozilla).
PHP hasn’t had a large corporate backer for a while. As far as I know, only one PHP core engineer is paid to work on the language full-time.
Large corporate sponsors can be great for a language. Sponsorship sends a message to other companies that “we trust X to help run our billion-dollar business” and also “if you use X you’ll benefit from the work we’re putting into it”.
PHP’s community is pretty strong, though, and has produced some great pieces of software that have moved the entire ecosystem forward.
Many beginners, few experts
PHP is very easy to get into, and it’s easy to make things in PHP that other people find useful.
PHP’s community is also sort of like a high school, where other language communities (e.g. Rust) are like universities: the teachers in a high school can make you a productive member of society, but if you’re looking to surround yourself with professors who are specialists in things you find interesting, universities are a better bet.
This reputation problem isn’t unique to PHP – other popular interpreted languages like Ruby have it too – but it can deter people who want to feel smart when writing code.
JavaScript had this problem for years, but in the last decade several big internet companies have thrown tons of money at its language ecosystem, and JavaScript experts are now plentiful.
It has many minor potholes
API inconsistency comes up repeatedly in peoples’ criticism of PHP. While it’s something the vast majority of PHP developers get used to quickly, there’s no getting around the clunkiness of some core library functions: strpos($haystack, $needle)
vs in_array($needle, $haystack)
and array_map($callback, $array)
vs array_filter($array, $callback)
.
Where do we go from here?
People have been predicting its demise for a couple of decades, but PHP’s still a pretty popular option. Why? Despite everything written above, there’s never been a better time to start a new PHP project.
PHP now has a huge ecosystem of open-source packages, and its main download hub has been accessed over a billion times last month by developers around the world. That’s up roughly 50% from the year before, and doubly impressive once you factor in all the things PHP can do natively.
There’s also good reason to be optimistic about PHP’s future. Ten years ago, things were looking much more dire, but the community has invested a lot of time and effort into improving things:
-
Package management
Composer, introduced in 2012, has made setting up a new project a breeze -
Static analysis
A bunch of great competing static analysis tools (including my own, Psalm) have been released in the last five years -
Raw performance
At Vimeo time spent in PHP itself has roughly halved since we upgraded from PHP 5 to PHP 7. Each new version squeezes out a little more speed, and PHP handily outperforms similar interpreted languages like Ruby, Python and Node -
Standard ways to write modern PHP
PSR emerged from a primordial soup of spaghetti code, and now pretty much all modern PHP looks very similar