Choosing PHP in 2022 and beyond
longhornphp.com
longhornphp.com
Static typing: We're not there yet. Lack of generics means arrays can contain anything. Not even close to TypeScript, and let's not compare to functional languages. Types in PHP is still duct-tape.
High performance: Nope. PHP is fast compared to what PHP used to be, but PHP is not fast compared to compiled, optimizing languages. I'm sorry, but this claim of PHP being a performant language is either delusional or unambitious. I basically have not been in contact with PHP in the last two years where performance wasn't a serious problem.
This isn't entirely because PHP performs bad, but largely because PHP programmers, on average, have a weak understanding of CS principles. I don't mean to bash any individuals; I saw a talk by a PHP programmer, whom I have great respect for, as late as yesterday. Incidentally, the talk was about how to make DSLs in Rust.
Maybe if all you did was PHP, PHP is pretty great.
The killer feature of PHP is that you can always find cheap labor.
Well, duh. It’s fast for its class of language.
> but largely because PHP programmers, on average, have a weak understanding of CS principles
Way to generalize and dismiss a whole class of programmers in the field.
Do better.
You mean loosely typed scripting languages?
I won't disagree with that.
> Way to generalize and dismiss a whole class of programmers in the field.
I don't intend to be mean.
PHP programmers have fewer years of formal CS training, on average. This isn't controversial.
Outside of generics, what else are you missing right now in PHP's type system?
> PHP is fast compared to what PHP used to be, but PHP is not fast compared to compiled, optimizing languages
The real question is "is PHP fast enough", and for the vast majority of use cases - including many you might not realize - it is.
In other words: PHP almost has generics.
If you lock yourself to an editor that makes a MacBook Pro 2020 seem weak.
These were added to Java 5 in 2004. You don't have to use a specific editor.
> Outside of generics, what else are you missing right now in PHP's type system?
Besides generics on functions, generics on data structures, i.e. be able to define a data structure that specifically fits a parameterised type of thing into its fields.
Type inference -- you need strong typing before this is possible, and PHP's duct-tape typing isn't enough (yet).
Algebraic sum types. Rust proved that you can have these without going full functional.
Pattern matching. PHP is trying to get there [2], but C#'s "value types" [3] just have better semantics for getting there in a decade.
PHP doesn't just suck because it misses stuff.
The things that it does include are made strangely bad.
Traits (type classes) -- I don't mean "PHP traits", but traits as understood in Scala or Rust, or type classes in Haskell. They're more like interfaces. PHP traits are like C#'s extension methods. Reasons why those are not so good that also apply to PHP: It's not obvious where they're defined, extending 3rd party libraries breaks encapsulation, can't be mocked. PHP programmers will pure-heartedly explore their options and make worse code by applying PHP traits in any context other when you utmost have to. Which is pretty often.
> Is PHP fast enough?
No.
Performance is something you gradually realise you need.
Just because most people don't need PHP to be a performant language, does not make PHP a performant language. You're just lowering the bar. If you make real software with PHP, because, you know, it has really grown as a language, then you'll experience performance problems sooner rather than if you'd picked a compiled, optimizing language.
[1]: https://stackoverflow.com/questions/312184/disadvantages-of-...
[2]: https://wiki.php.net/rfc/pattern-matching
[3]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Nope, they use PHP because it takes the least effort to make something work. It is almost universally supported, it does not need a complicated build infrastructure - looking at you here, "modern" Javascript (among others) - and it has most of the bits needed for the average web thing included. All it takes is a single text file with a .php extension and you're off to the races while those using "superior" languages are still getting their build chain up and running. Maybe the end result using one of those "superior" languages is more performant, maybe it is easier to maintain, maybe it is less prone to breakage - all can be true. None of these are the first thing thought of when you want to get something up and running quickly and relatively effortlessly. For larger projects these things become more important and that is where those "superior" languages can actually earn that label but for a large part of the web things built PHP is just fine.
Lot of the points you described seem unrelated to PHP but just incomplete views based on your own premature judgements because you dislike PHP.
So is cocaine.
PHP is popular because it is easy to get started with.
PHP is in demand because popular software was made in PHP.
Those are good qualities of PHP. PHP's insufficiencies as a type-safe and performant language are not among those reasons.
> Lot of the points you described seem unrelated to PHP but just incomplete views based on your own premature judgements because you dislike PHP.
I'm not sure what makes you think that my judgement is premature.
I wrote PHP for a lot of years since 2004.
I don't normally bash PHP. It is too easy, after all.
But when some blog post says that PHP is a strong choice in 2022 because of strict typing and performance, I have to beg to differ. You will see commenters consistently downplay performance as "you don't really need performance on average", as if not needing performance constitutes having it. And similarly, you will see commenters say that it does have enough typing, which is of course subjective. But what is "fully typed", as the article refers to? If I have an array, can I say what kind of thing goes into the array, and will it be a type error if I stuff something else in there? Can I declare something as not nullable? If not, what's particularly "full" about this?
I'll admit that I personally don't care about generics (and static typing), but I find types in TypeScript more cumbersome than in PHP. Maybe that's the price to pay for extended capabilities.
Also I do Elixir professionally, which you'll agree is a functional language ;), and I would take PHP strict typing & type hinting any day over what we get in Elixir.
Performance-wise I would say it's OK these days, in a web context most of the problems come from complex data layers, like nested data in a rest api, which caching can't always solve.
It will never be as fast as Go, or Rust (or Elixir), for sure.
On the other hand, PHP 8 + Symfony + PhpStorm give you an insanely productive platform and amazing DX experience.
TypeScript really is a feature of JavaScript in many ways.
I have a hard time going to another language that requires appending semicolon at the end of each line, dealing with curly brackets, and requiring a bunch of middlelayer tooling.
I'm willing to bet that I can train someone without any coding experience in Python. It's built for readability and very accessible. Javascript? No way I would introduce them until they get some handle. PHP? Not unless I am trying to create a sweatshop.
I doubt it, maybe some hyper genius, you need to try and see how someone new to programming understands thing. Stuff that is super obvious to us is just unclear for a new person.
PHP was started more as a quick hack by a single developer just playing around. More and more stuff got tacked on and the result was a steaming mess. It's been busy fixing its conceptual mistakes since version 3/4.
PHP’s lack of coherent style and the persistent thrill of not knowing which horrible errors it’s willing to silently swallow and proceed, on the other hand, are (were?) much harder to tolerate.
EDIT: Don’t want to start a flamewar, it really has improved over the years. Nonetheless, it has a less than bright past.
You'd need someone with unimpeachable domain knowledge and ready access to asbestos underwear to deliver it though!
Anyone writing comments about "scaling" or "performance" has never had to deal with a half-baked application written by some junior node.js developer who thought their microservice had to be Internet Scale(tm)
PHP is a great choice in 2022. Hell, it'll be a great choice in 2032 I'm sure. The tooling and debugging that PHP provides is incredibly powerful. Developers are easy to find, it's easy to pick up (which sure makes it easy to get wrong), but those who get it right will do it incredibly well.
Arguments against PHP are lead by developers who think they're smarter than they really are.
$result = $someCondition
? $foo->abc()
: $foo->def();
And for what's not a monstrosity to begin with... It's not a monstrosity to begin with, you ain't gaining much
double piecewise(double x)
{
return x < 0 ? x*x :
x < 1 ? x :
x < 5 ? x*x-x+1 :
21.
}Newcomers should learn to use something else. Go, Ruby, Python, Node, Nim. The tools are better, more modern, with broader library support, and you can use the languages in more ways throughout your career.
Re: "tools are better, more modern, with broader library support" - I would need a lot of evidence to convince me this is the case, particularly for Ruby and Python.
Both Django (python) and Rails (ruby) are great, popular and well supported environments with very "broad library support". This is a bizarre statement.
People that talk about PHP not being modern normally also stopped looking at PHP around PHP4....
Making a Website with Go would be hell, but for network and api stuff it’s a good choice.
The right tool for the right problem.
Today we build frontend in Javascript. Tomorrow we shall build them ALL in Python. Backend AND frontend!
A good developer will not be an extremist fanboy for a language or framework, otherwise he will reinvent stuff in his cool tech because he does not want to learn.
But I agree for someone new start with JavaScript, but if someone will pay you to work with PHP take the money, learn modern PHP, use a good IDE and you will be happy.
Or, better yet, you load a billion deps on every request and your request time is atrocious.
I've had the exact same observation.
Today, you'd be much better off picking up a language that provides concurrency primitives and has tools to build simple pages w/ a request/response flow.
Just my $0.02
This was true 10 years ago. Not so today - the tools are there, and the frameworks are making it simple to deploy them.
https://twitter.com/aschmelyun/status/1548270721964462081
https://laravel.com/docs/9.x/octane
https://openswoole.com/article/symfony-swoole
But more importantly: the vast majority of apps don't need this. PHP by itself is fast enough for most use cases when set up properly.
There is some shared context that is session for example but how I understand it each request is concurrent anyway.
Is there support for running single script continously?
Only thing I've ever seen that can compare with Laravel is RoR which for whatever reason I've never taken to, but I see the benefits and the story there.
I mean PHP is generally faster than python and has better support for setting up sites quickly (esp in reguards to cost). PHP has a sane package system. I don't know I think you are selling it short.
PHP is a fundamentally broken design for a scripting language and the decades of heroic work from its maintainers cannot change that the basic underlying design was bad from the start. You can only fix so much without just devising a new language from scratch and somehow getting people to migrate, and at that point, they could just migrate to a language that doesn't have all the baggage and a bunch of old (now inaccurate?) documentation and old broken code floating around.
At one of my first paid engineering gigs we ran a social game for 10m+ users where all of our online services were backed by PHP - live chat and state updates for the game's native PC client went over http and were stored in memcached/sql, we did transaction processing for user-to-user cosmetics sales, we had forums and custom user home pages, etc. Underneath all of that we had to build some complex systems so we had weird things implemented in PHP like distributed locks for cross-server concurrency (yes, really). We were able to get a lot done in PHP, which I guess is to its credit!
On the other hand, PHP was a constant nightmare. Every single line of PHP we deployed was a liability and a lot of it was stuff we didn't have much visibility into. Once some random popular package we used for our forums - the coppermine photo gallery i think? or maybe phpbb itself? - was used by an attacker to jump in and exploit vulnerabilities in OTHER popular php packages we were using like osCommerce and clear all our payment processing configuration, making everything free without registering in the logs. I spent probably upwards of a dozen hours that friday night and early morning reading over every line of those packages with some colleagues to try and figure out WTF was happening, and it was SO difficult to do that audit because every single line of PHP was potentially hiding an assassin that wanted to stab you in the neck. To be able to ship and maintain our software at all we had to write an incredibly extensive set of automated unit and functional and integration tests, we required regression tests for every single fix and multiple tests for every new change because without that kind of rigor it was impossible to run a real service using PHP. Naturally we had to build most of the automated testing infra ourselves because the state of the art PHP testing frameworks were bad.
Later on we had another fun bug where the PHP unserialize() function was deserializing 4.0 into 12.0 (yes, really... though it may have been a different constant). I spent hours w/a colleague reading over PHP's C implementation trying to puzzle out how this could happen and in the end the conclusion we came to was that a .dll our payment provider required us to run in the PHP server was changing the floating point rounding flags for the thread, and not only did PHP not control its own rounding flags but it was extremely vulnerable to having them changed. Frustrating. (This is of course something that could happen with any language, but the low quality of PHP's underlying implementation made it more impactful)
Also... WordPress. When's the last time someone ran a wordpress install without it getting hacked? I don't think I know anyone who's successfully kept one up without getting owned. I lost at least one website because the shared hosting instance kept getting hacked via other people's wordpress installs until the server's owner gave up and took it down.
Over time PHP certainly has improved but I've used dozens of horrible languages and I think I would pick almost any of them over PHP if only because every time someone I know has used it they've ended up paying for it later. I would sooner write tens or hundreds of thousands of lines of VB6 or Perl or AS3+Flex than have to write and deploy a thousand lines of PHP because I just know the PHP would end up being a liability somehow.
If I could wave a magic wand and disappear one piece of software from history, it would be Bitcoin, but if I had two choices the second one would be PHP. Of course, this would probably be a setback for the progress of technology somehow since PHP empowered a lot of newbies and amateurs to ship working software, but we need only look at the long trail of mayhem and sorrow to see the cost they paid for shipping it using PHP.
It's unbelievably improved from the days where you could write spaghetti code.. they really put a lot of effort into beat practices.
> PHP Is the Right Choice in 2022 and Beyond
If you were using PHP in, say, the year 2000 you were an amateur programmer, albeit likely a productive one. Amateur, because if you knew better you'd stay away from the dumpster fire that was PHP.
If you're using PHP in 2022, you need to have your head examined.