I've worked with PHP throughout 2020, and it is still the worst crap I know.
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.
PHP is still very much in demand and used widely so I wouldn't call it crap. On a surface level it has shortcomings but most of these are non-issue for most of its use base.
Lot of the points you described seem unrelated to PHP but just incomplete views based on your own premature judgements because you dislike PHP.
> PHP is still very much in demand and used widely so I wouldn't call it crap.
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?
> 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.
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.
You can write PHP with generics via docblocks that are understood by PhpStorm, the two leading static analyzers (PHPStan and Psalm), and soon by the Intelephpense plugin for VS Code. Since the main advantage for generics in a language like PHP isn't at runtime, this is pretty good support.
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.
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.
...and still people use PHP over Scala or Rust or any of the plethora of "better" languages. Is this because all people are just uninformed, not knowing enough to be able to choose one of those "superior" languages?
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.
Working with a language (for first time?) in one context/project/environment for one year is enough to generalise about the average skills of many thousands of professionals?
If I were in charge of giving out awards I would give PHP the "Most improved language of the 21st century." PHP3 at the turn of the century was trash but it was easy to build websites with it and it was easy to find people to do so for you. PHP8 is a world away from PHP3.
Python is a better candidate imho mostly because of the explosion in its use case in the past decade, especially due to data science/AI fields.
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.
Python was started from the educational side of computer science. As such its core concepts and architecture are solid.
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.
>I'm willing to bet that I can train someone without any coding experience in Python.
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.
I find Python quite easy to read but I still prefer C-style code without significant whitespace. Those braces make it far easier to spot block level errors, especially when using some form of auto-indent or a linter. Semicolons are less important - I hardly ever concatenate lines of code - but they don't bother me either.
JS has grown a great many tools, libraries, and features, but as language semantics go it’s hard to say that primordial JS was seriously broken anywhere. Coercions, maybe. It’s not a language I can love, but it’s one I can accept.
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.
Reddit’s r/lolphp has some “great” memories of many of the shortcomings (most of which are historical now fortunately). My favorites are probably the randomly long and short function names, due to length being used for hashing, and DATE_8601 not being compatible with ISO-8601.
EDIT: Don’t want to start a flamewar, it really has improved over the years. Nonetheless, it has a less than bright past.
Let’s be honest, both language had place for improvements (other languages didn’t leave as much to be desired), and fortunately both became quite usable nowadays.
Maybe you're not a PHP developer, but you probably have some kind of skill to teach others! We're looking for talk ideas on a variety of topics such as accessibility, devops, frontend, testing, programming patterns, tooling, and more. I wrote up this quick post to tell you why PHP is still relevant and why you should consider sharing what you know with PHP developers.
As a talk idea, "Everything you know about PHP is wrong" has no direct hits as a phrase search on google, and, judging by the comments that PHP generates on hn, might have some mileage.
You'd need someone with unimpeachable domain knowledge and ready access to asbestos underwear to deliver it though!
I've been using PHP for our latest venture after 8+ years of node.js and it's become the de facto language to use at our company.
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.
I'd kinda like to see a language that allowed ternaries but only when the components were sufficiently simple, e.g. no compound ternaries or even no more than a single arithmetic/boolean operator.
Though enforcing it with linter rules is probably the better option.
The problem with ternaries is people getting so excited about it they build some one line monstrosities that really should be broken down into more lines
And for what's not a monstrosity to begin with... It's not a monstrosity to begin with, you ain't gaining much
I believe parent commenter was thinking of if expressions, which are quite similarly short - and I’m also on the opinion that they are much more readable and less prone to mistakes (like how does nested ternaries operate in your given language)
PHP is great for people that know it and are productive in it. For legacy codebases and software.
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.
I am not sure I would start a side project in PHP, but I will disagree that the other languages have better tools or libraries. For doing your job most of the time the language is not the issue, real work in my case is mostly related to thinking at teh problem, researching and implementing solutions, PHP allows me to write solutions and when the right tool for the job is a CLI tool (like ffmpeg or ghostscript) I can use it from PHP, if a bash script can dsolve a problem I write the solution in bash and use it from PHP, and I had a problem where Python was pefect, we made the Python solution and integrated the mainPHp app with it.
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.
Which is why I favor Python so much. You can literally do anything with it since it is in every field: finance, data science, AI, API, SSR and thanks to transpilers and efforts to bring python to the browser, frontend is now possible.
Today we build frontend in Javascript. Tomorrow we shall build them ALL in Python. Backend AND frontend!
I agree with you on portability. If that's a concern, and you're a web developer, I'd say TypeScript is a more obvious choice than Go, Ruby, etc.
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.
> 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.
So your defense of broader library support is that each of them have one framework to choose, where php has dozens of web frameworks, all of which have broad library support (often sharing libraries between them)
I always get a kick out of seeing the HN Who's Hiring thread and searching for "PHP". Results in actual job requirements are rare, but most URLs people link all end with .php. It's such a funny double-standard.
Every php project ends up hitting the "php lifetime of the request", writing a terrible cronjob system that never works and you get super into the weeds of debugging some garbage job system.
Or, better yet, you load a billion deps on every request and your request time is atrocious.
despite it's terrible APIs it was fast and easy to setup and manage. Speaking from over a decade ago here.. My experience was good with PHP for simple web applications. However any form of concurrency can't easily be achieve with PHP, so that limits the types of applications you can build easily.
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.
From my understanding of how php works it should be "concurrent" by default - each request is handled by web server and then php interpreter is running code in concurrent manner.
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?
Your first point assumes that you always run a web application. PHP can be used for general purpose scripting as well. Also even on a Web context how would you support websockets with traditional php? You can how achieve that with swoole.
Honestly, I find Laravel to have more activity happening with it than Django.
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.
What kind of concurrency do you have in mind for a web app that can't be addressed by worker/queue set-ups. At least that's what I do in my PHP (and Python) web projects that need concurrency. Laravel has support for a number of backends for managing queues that are written in $not_php [0].
It's impossible for me to take anyone seriously if they suggest picking PHP for any new project or deployment. Yes, there are existing high-quality services and libraries written in PHP and some of them have amazing communities, but that's true for any programming language, and many of those other programming languages aren't PHP. I recognize that people have extensive investments in PHP, and I won't tell them that they have to throw that away, but don't try to drag newbies into the muck, please.
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.
Sorry your experience with it sucked - but that's simply not what it's like writing PHP today in a modern framework. It is literally a joy to work with for thousands upon thousands of people (and not just the newbies).
Php will never be able to shake off its legacy. It’s a lost cause imo. Which is a shame since it’s faster than most (all?) languages in common use for backend development of websites.
The many people posting Reddit-like spam comments (ie zero value, attack focused) in this thread are not attempting to have a dialogue. They're just here to attack.
It's a British phrase I believe. Essentially a different formulation of "you're pulling my leg" where instead of asking you to stop they ask you to distribute the pulling evenly.
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.
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.