1004
PHP is dead?
(telegra.ph)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Oct 2023
1004 points (96.3% liked)
Programmer Humor
32371 readers
562 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
https://w3techs.com/technologies/overview/programming_language
On the server-side PHP is used by 76.8% of all websites (a large chunk of that being WordPress). It is not going anywhere, soon. Looking at this statistics, nothing else seems to be even in the same league from a pure usage point of view.
I have yet to see a reason why it should change. Serious question: What is the disadvantage of using the tried and tested PHP8 compared to the alternatives, if you already know PHP?
Serious Answer: PHP in itself is not that bad, despite some discussable decisions in function naming and arguments order to name a few. The biggest problem, is that it has a settings file describing how it works (php.ini) and that sh*t will bite you in the rear when you move apps from server to server, where all the libs are different etc... PHP never works out of the box when moving something on a new server, that is the worst part of the language.
Maybe the issue in your example isn't related to "how bad PHP is" but is to "how bad the code you're referring to is". Never had those kind of issues and yes obviously you've to know what extensions an application is using, but once again, modern PHP applications usually use composer as dependency manager and will gave those specified inside the project.
Good on you to not have to maintain legacy code (15years+). Also, as a comparison, with JAVA, I have a legacy JAVA 1.5 to maintain, as far as you have the runtime, that stuff works, and that's it. This is how it should be.
I do, the difference is that, unlike Ruby code bases, it happens to be supported languages that evolved and perform better today.
Poor performance, execution model limitations, lack of static typing (although they seem to be working on that), and general legacy cruft.
Don't compare PHP to Node, Ruby or Python, they also have problems. I think Go is currently the best choice for a web backend; an objective evaluation of PHP and Go would certainly put Go ahead. If you know PHP, you can pick up Go in a day or two, so I don't think that's a great reason to keep using PHP either.
Usage statistics are a highly misleading, software projects take several years to develop and a majority will fail. Looking at current usage tells you the most popular choice from 5 years ago, not today. Over 90% of video games published in the last 5-10 years use Unity or UE4, but these probably aren't the best choices today.
Yes for performance running code, for performance as in "developer time" PHP is way faster. Go is solid but developer take more time implementing stuff with it. Use PHP for everything business related except for that one or two cases where you really need the performance that Go provides and where it is worth the extra dev time.
Easy example. Have they fixed file upload behavior yet? Do they store the entire file in memory by default instead of chunking it and storing it as it comes in?
If not it's like the worst memory usage of any language possible.
If you have to go change the php.ini to adjust file upload sizes, it's not really moving forward and is decades behind other languages.
File upload behavior is actually determined by your web server (unless you're launching PHP in listening mode) so apache is probably who you want to blame here.
Other languages behind reverse proxies from apache httpd or nginx do not have the same memory hit. You can still blame php. Not my fault they tied their language to the webserver in a way that uses tons of extra memory.
Are you in 1995? PHP dynamically decides how to manage uploaded files, it will generally store a few MB on RAM and move it to disk after that point. It also support streams so the backend can take the incoming data live and do stuff with it without storing it first as usual in the classical model. There are also plenty of higher level solutions to deal with chunked uploads, mobile clients disconnecting such as https://tus.io/ that are used by large companies like Vimeo.
Most new PHP apps I know implement chunked uploads themselves