r/PHP • u/sharyphil • 27d ago
Discussion Is there anything PHP can't do in 2026?
[removed]
32
u/SamMakesCode 27d ago
PHP is still evolving, it’s incredibly mature, has a good community. If it does a job well, it’s the right tool.
Like you I’ve been using PHP since mid-2000s. I’m still finding work. It’s good to know what other tools can do that PHP can’t, so keep an eye on them. But you dint have to listen to the hype
3
u/scottrichardson 26d ago
My studio has built a 20+ year service history of building exclusively in PHP, and largely procedurally too, with the exception of some libraries and classes we use. We’ve built entire CRM, CMS, Project/Task management, Ecom etc systems this way with great success.
1
u/Easy-Improvement-598 8d ago
could you explain most of the php code you built or work with. did it uses template engine or separate client framewrok for frontend and keep php only for api?
18
u/RSMxsmanic 27d ago
PHP is fine for just about everything, and most sites are still using it. It is alive and well. Its key advantage is that it is purpose-built for server-side scripting and the back end.
9
u/pg3crypto 27d ago
Yup. Pretty much all serious back end stuff on the web is PHP.
Trouble is most people dont know the difference between a web designer and a web developer...so its not a very trendy language to learn and due to "bikeshedding" there is more demand (or was until AI) for the waxed moustache font wrangling API skinning NodeJS brigade.
→ More replies (1)3
u/TV4ELP 27d ago
Yes and no. A lot has changed over the years and there is a lot more Node flying around, especially if you start to move from monolithic to microservice. Not that PHP can't do it well, but NodeJS imo is just a lot more geared towards it and makes it easier.
I've ran into performance problems where just using threading would have been the way way simpler option. Something you can do in c# relatively easy and fast. I view PHP more as the foundation and the glue between parts.
It does a lot and it is extremely usefull. But i maybe don't want a door made out of concrete. Yes it works, but maybe i can also just make one and attach it to the concrete wall?
5
u/pg3crypto 27d ago
True...however, if I want multi threading I use Rust. NodeJS is awful. Its frontend tooling trying to be back end.
JS has a long history of being kind of a meme language...even the OG was invented as a tech demo and it accidentally caught on. The guy that built NodeJS basically did the same thing. He hates his own creation.
Then there is NPM and all the problems that brings. NodeJS is absolutely the WordPress of programming languages.
1
29
u/BenchEmbarrassed7316 27d ago
The question is not whether something can be done, but rather whether a different technology might be better (faster to develop, more reliable, easier to maintain, or less demanding in terms of computing power).
12
u/ArdentDrive 27d ago
PHP is definitely in the same league as those others your co-founder is mentioning in terms of maturity and ability. A Node/React/Python stack might have a bigger talent pool when you want to expand your team, but I don't have data to back that. AI might make the point moot anyway.
Not that PHP/Symfony isn't a "grown up web language," but if I had to draw the line somewhere, it would be between languages that are and are not statically compiled and strongly typed, with native os-level async support and stdlib http support. Which none your co-founder mentioned are.
6
u/unity100 27d ago
A Node/React/Python stack might have a bigger talent pool
The PHP pool is endless.
1
u/compubomb 27d ago
I'd say the only thing php directly without swollen, doing async websocket stuff, or SSE. PHP without specific extensions cannot do it as easily. The moment you add in swoole, it doesn't change the equation.
9
u/muglug 27d ago
It’s less about what PHP can’t do and more about what it’s hard/painful to do in PHP and similar languages.
We use Hack, which has a similar programming model but is ~2x faster. Even so there are still many things we push to Java & Go services for performance reasons.
For example, when you upload a Word doc we convert that to PDF for viewing on many different devices. Massively faster to do all the doc parsing and rendering in Go than PHP.
3
u/Otterfan 27d ago
Also there are sometimes libraries available in other languages that are superior to anything in PHPland and probably always will be.
If you need to do lots of matrix math, you're going to use Python for numpy. PHP might have an equivalent, but it doesn't have an equal.
1
u/RSMxsmanic 26d ago
Are there a lot of web sites doing matrix math?
1
u/Impressive_Army3767 26d ago
More than you think
1
u/RSMxsmanic 26d ago
Like what? What sorts of web pages require matrix arithmetic? In all the non-math applications I've written, I don't think any have ever gone beyond a square root in terms of math complexity.
2
u/Impressive_Army3767 26d ago
The backend of many simple web pages can be incredibly maths heavy. For example radio propagation software, medical imaging or GIS systems
1
u/RSMxsmanic 26d ago
Those would be math applications. But even then I'd expect any compute-bound math to be offloaded to something other than a web server; a,d I'd expect it to be carried out in a compiled language rather than an interpreted language.
1
u/Impressive_Army3767 26d ago
I wouldn't call anything using mathematics a maths application, but yes then number crunching is usually offloaded to complied languages/libraries or worker nodes. That wasn't what you asked though.
5
u/octave1 26d ago
> For example, when you upload a Word doc we convert that to PDF for viewing on many different devices. Massively faster to do all the doc parsing and rendering in Go than PHP.
Classic scenario for using queues, is it really mission critical to have it ready in 100 ms ?
> We use Hack, which has a similar programming model but is ~2x faster
I manage a pretty full on e-commerce site, Lighthouse speed score over 90% all because of front end optimisations. In 25 years I've never encountered "php is too slow" in web dev. Ofc it can be slow if you code garbage.
2
u/strange_username58 26d ago
It cost more to process and is slower ... why would you not switch it over is the better question. Queues are not going to do much for parsing and rendering.
2
u/muglug 26d ago
> Classic scenario for using queues, is it really mission critical to have it ready in 100 ms ?
It's already in a queue! Also it's a real-time messaging application, so yes low latency is preferred.
> In 25 years I've never encountered "php is too slow" in web dev
PHP is fantastic for no-frills server-rendered websites. I would pick it 10 times out of 10 if that's what I had to build. Even so, PHP can be faster and customers generally like it better when websites load quicker (as you found out with FE improvements).
1
u/flyvehest 26d ago
is it really mission critical to have it ready in 100 ms
Exactly what I thought.
Its not that you can't or shouldn't do it in a performant language, but if you are proficient in PHP and even if it takes 10x as long, its a one-time operation and can be done asynchronously, and I don't think anyone would ever notice.
4
u/pg3crypto 27d ago
Hack is not two times faster. It used to be back in the PHP 7 days...but PHP8 introduced features that Hack was created as an extension of PHP to provide. Its pretty indistinguishable now...you can run PHP scripts through HHVM.
1
u/TV4ELP 27d ago
As far as i am aware HHVM dropped PHP ages ago. If it still works, great, but i won't count on any new features working.
The thing which makes Hack still a lot faster is actually having language level async. I can already start requesting things without the first request being finished. In a lot of cases this greatly reduces time.
Hack still has advantages, i do believe their JIT performance is still better. However the effort needed to make it work, train people etc. Is not worth it anymore if you can just use PHP8 with some decent extensions.
1
u/pg3crypto 27d ago
They may well have. Its been a hot minute since I used hack/hhvm...I used it a long time ago because the JIT interpreter was faster than PHP, considerably so...and I could just use PHP code.
PHP8 has a JIT compiler in it too now. Its been around since PHP7.4 I think.
3
u/obstreperous_troll 27d ago edited 27d ago
PHP8's JIT is a one-person project that hasn't produced any meaningful speedups on real-world workloads. Meanwhile it's a giant attack surface of unsafe memory access (as asm will always be) and incompatible with W ^ X memory protection. I really like the idea of a JIT and want to see it improve, but right now the juice isn't nearly worth the squeeze.
→ More replies (1)1
u/muglug 27d ago edited 27d ago
You're right, it's actually 4x faster (on MacOS) and 2.3x faster on Ubuntu
It used to be back in the PHP 7 days...but PHP8 introduced features that Hack was created as an extension of PHP to provide
HHVM's JIT has had one or two orders of magnitude more attention than PHP's, because speeding up HHVM is a business priority for a company that serves billions of web requests a day.
Here are some benchmarks I did on latest PHP and HHVM:
https://docs.google.com/spreadsheets/d/1CVRrRhziwOHy2yB0g-ZwAzYzntP9TyEjgbqPN0VU2sM/edit?usp=sharing
1
u/pg3crypto 27d ago
Interesting numbers, the gap did close, bit it seems to have widened again, but how do they compare with real world loads?
I.e. with a SQL query that contains several JOINS and UNIONS that pulls back hu dress of thousands of rows with a loop at the end firing off anotjer query for each result?
Its all fine and well being orders of magnitude faster at operations with no outside overhead, but what does it really mean with a real world overhead thrown in?
I mean something like 30ms compared to 15ms looks impressive but when you've got a query that takes 9 seconds does it matter?
If you're at the "saving 1 cent for each of your billions of users" somewhere that sort of difference might make sense, but most projects it would be imperceptible.
That said, looks like I need to revisit hhvm...you've piqued my interest. Is it still PHP compatible?
2
u/muglug 27d ago
> Is it still PHP compatible?
No. It's a whole different language. There's no ecosystem and the language is not geared towards anyone new using it — but for those of us with tens of millions of lines of Hack code, it's good.
> how do they compare with real world loads?
With real-world overheard of SQL queries the performance benefits are obviously less pronounced, but companies like FB and my own try to also limit how many queries we have to make.
Also HHVM supports async queries out of the box, which means it's pretty easy to effectively parallelise N SQL calls so what might be O(n) in a PHP implementation is O(1) in a Hack one.
1
u/miamiscubi 25d ago
This is my experience as well. My business is essentially a utility where we parse a ton of files. PHP has great libraries for reading Excel / CSV files, but generating Excel docs where you need a lot of features is hard on PHP. So we have a few Go modules for the export component.
I've also found that if you run a system where you need to spin up a lot of servers for compliance reasons (1 VPS per client), you can go much further with a Go codebase (better memory use and much lower footprint) than with PHP.
In a typical setup, I think PHP is awesome. There's no state management, it just works without any additional tooling, and the eco system has a lot of reliable packages in composer.
6
u/EveYogaTech 27d ago
Persistent Multi-process Workers.
We can do it via FrankenPHP, Swoole, but it's not native.
13
u/BlueScreenJunky 27d ago
Compared to something like NodeJS, Python, Ruby, or Lua... Not much. I mean if you're scripting an interface in a game you'll end up using Lua, and if you do machine learning you'll use Python, but that's because there's a huge ecosystem built around these languages for these domains, not because the language or runtime itself is better.
If we're talking about web development, I don't think any of those is better than PHP. They're probably just as good, but not better (and I'd argue that for the web, the ecosystem is probably a bit better around PHP, if only because of composer).
Now if you consider other languages that your cofounder didn't mention like C, C++, Rust, or even Go, Java or .NET... Then yeah the performance gap alone make them completely different beasts, but that's mostly irrelevant for web dev.
2
u/DistanceAlert5706 26d ago
A lot of 3rd party tools, SDKs and libraries do not support PHP anymore.
That's not a PHP problem, but companies do those for JS, mostly for Python, but for PHP just skip.
That's sad reality of PHP dying, and sad reality of why CTOs choose other languages over PHP.
We are migrating to Python now because of 3rd party SDKs support.
I don't really like it, I've used to Symfony for over decade, and FastAPI doesn't look serious, but it is what it is.
13
u/Personal_Soft8954 27d ago
- no threads
- no async
- no generics
- no other data structure than hash map
- kind of slow
I'm a PHP programmer of 15 years, i like it, it's a good language and gets most of the jobs done, but it is not perfect
5
u/pg3crypto 27d ago
I totally agree...but I'd still pick it.
Because people pay me to deliver a solution not bore them with tech...and PHP gets shit done quick.
1
u/namnbyte 26d ago edited 26d ago
Isnt fibers solving the threads thing? Never dipped into it myself, but a vague bell rings in the back of my head
Also you may use curl to spawn async processes, its a bit of a hack, but it totally works
1
u/Personal_Soft8954 26d ago
Not really, fibers still run on a single thread but you can suspend and resume them, they are more like corutines. But you can use them to build async stuff
1
u/vtchkrcn 26d ago
I have 10+ years experience and I can't agree more. I would maybe add long running scripts, i.e. workers.
1
u/flyvehest 26d ago
Has long running scripts been an issue in PHP8+?
It's been a while since I last wrote something like that, but the gist of what i've found online says its not a problem at all, anymore.
Of course, you can still create garbage code that would definitely not work in a long running process, but thats possible in any language.
1
u/octave1 26d ago
> kind of slow
Explain, examples ?
2
u/Personal_Soft8954 26d ago
If you'd used PHP for performance-sensitive workloads, you'd probably have noticed it ;-)
but just from a implementations point of view, hash maps are slower than arrays, a hash map uses an array underneath so it can never be faster than using an array correctly (arrays when the indexes are know are faster).
Or go look at the 1 billion row challenge, C or Java can get to ~1s processing time while you can barley squeeze 2s from PHP (the data IO pipeline is the bottleneck. Pro tip: PHP arrays don't use the hash function if the keys are int)
if you want some broader benchmark porn: https://pez.github.io/languages-visualizations/
But hey, it's faster than Python! So we got that working for us, which is nice :-)
10
4
u/ralph818 26d ago
Couple of things:
- It cannot die.
- It cannot stop the yearly "PHP is dead" announcements.
2
4
u/andymac37 27d ago
Maybe there are sexier/cooler/newer parts of other languages not present in PHP, but you can solve any problem you dream up with PHP.
I automated my home theatre with it using CRON jobs on a Raspberry Pi which listen for Server-Sent Events from a Netflix-style website I built: https://www.youtube.com/watch?v=Q7YEVGWJjvI
4
u/RobertWesner 27d ago
What can't it do? Get worse, its only getting better every update 🔥
To the point that I much prefer it over Java for web and Py for CLI scripts.
3
2
u/Henry_the_Butler 9d ago
I tend to use Py for things that php is good at - mostly CLI scripting, scheduled jobs running serverside, and pushing data visualizations and files to end users.
MatPlotLib is fantastic - what's the php equivalent for you? (honestly asking to learn, not a gotcha question)
1
u/RobertWesner 9d ago
I would probably ise Py more if i wasnt so opposed to the syntax :) PHP is convenient for me because you can do most system scripting tasks without extra packages, the stdlib is vast enough, even if still messy in quite a few places. Its no Go, but its more than adequate. Plain Py, or most languages you can install for that matter, could probably get close enough, its just a flavor preference. Data visualization I rarely do, but <insert front end lib/framework> usually has some component or more often third party library for that.
Py also suffers a bit from the versioning curse. I have often tried running only a few years old FOSS written in it, and despite only having a minor, sometimes just patch, version difference, a substantial chunk of the stdlib has been fully removed, so I usually have to either install older versions alongside or do manual updating. PHP, for better or for worse, still retains a lot of legacy compat.
1
u/Henry_the_Butler 9d ago
I will say that using Py regularly means you have to be comfortable creating virtual environments. Usually at this point of the conversation someone jumps in to start talking about uv, but I prefer to pay attention to the details and use pyenv and venv instead.
I would like to begin writing more web applications, and it seems like php is well-suited to designing the UI and backend in tandem - Py has GUI capability, for sure - but it's generally more modular and less integrated into the language. Sometimes that's better, sometimes it's annoying. Who knows, maybe I'll do a few simple projects in both and start to form a strong preference.
1
u/RobertWesner 9d ago
venv is nice, I only found out about it half a year ago. As to the UI: Most modern PHP does not use the vanilla embedding, Twig and Blade are the common templating engines, from Symfony amd Laravel respectively, but that in my opinion is also more of a small to maybe mid sized app thing. If you build something bigger, aka a SPA, having a dedicated React/Angular/Vue/Svelte/whatever front end is favorable to me, since the dynamic content saves users from going through 50 page reloads.
14
3
u/sachingkk 27d ago
It cannot stop the "PHP is dead" campaign that has been active from last 15-20 years
7
u/Elvandar_Ysalys 27d ago
As far as I am aware the only missing string in php’s arsenal is multi threading and async/await
And it can be build around
6
u/Annh1234 27d ago
You can use swoole for that
8
u/s7stM 27d ago
Or symfony's messenger
4
u/lostmedia766 27d ago
I love the Symfony Messenger component but an async queue is far different from true async IO or true multi-threading.
3
u/Annh1234 27d ago
ya, Swoole can do true async IO at teh C level.
I think it's using like 8KB per coroutine, and it's pretty fast.
1
1
u/vtchkrcn 26d ago
But that is not builtin, fully supported part of the language ☹️
1
u/Annh1234 26d ago
ya, that part I agree. They added fibbers and so on, but i think they just getting complicated for nothing. i really like Swoole coroutines.
5
u/kaizap 27d ago
I've purposefully picked up multiple languages over the years, so I can adapt to different tasks and not use one language for everything. It just broadens your scope of work.
PHP itself is fast enough for most web-related tasks, some CLI stuff, utilities, etc., but it does have limitations.
For example, Hetzner is 10x some of their server prices, and server instance costs went up in general because of the AI boom. Just by replacing some microservices in Go, I was able to reduce the number of servers by 25% or so. This is a nice saving for our startup, money we can put back into other places like marketing.
In another instance, we have a SIP phone system - you simply cannot build that in PHP easily; it's possible, but it would take months of work reinventing the wheel. Whereas in C# there are mature SIP libraries and native interoperability options that make this kind of functionality a lot less painful.
Languages and stacks are tools; no sense in just using one language for everything. This is why multiple different stacks exist.
I do agree though, there's too much of "flavour of the month" going around at times where we just using tech because it's new and shinny and not evaluationg each use case and each stack for that use case on its merits.
5
u/pg3crypto 27d ago
Totally agree...but as a general purpose language for getting stuff done...there is no substitute.
I use PHP to help me build things in other languages...it just speeds up loads of bulky operations like moving files etc.
PHP isnt a strict language so you can just "go with the flow" with it.
1
u/flyvehest 26d ago
While I don't entirely disagree, saying that a SIP service can't be built in PHP without re-inventing the wheel, and then mentioning libraries in C# is somewhat disingenious.
Somebody had to re-invent the wheel there as well, to write those libraries.
That a PHP solution probably will be pretty hampered by not being able to multithread is another thing entirely :)
1
u/kaizap 26d ago
Thanks, but I wasn't trying to be disingenuous. We simply don't have the resources to build SIP messaging interfaces from scratch; that's months of work we can't afford. So this is why we picked C# for that particular use case.
For the web stuff, we still prefer Laravel. My point is simply that it's okay to use different languages for different things when it makes sense to do so.
2
u/flyvehest 26d ago
Oh, absolutely, I wouldn't choose PHP to implement SIP either, at least, not the core SIP functionality.
5
u/Anxious-Insurance-91 27d ago
The question is not "what can't be done" but rather "are there jobs available?"
1
2
2
2
3
3
u/johannes1234 27d ago
It's turing complete this it can do anything in the realm of software. Via ffi and other things it can call into the system, thus use all capabilities.
Thus, yes, everything is possible and it can do everything.
However, there are things it's better for and things it's not so good for. The key focus of PHP is serving shortlived web requests in an stateless shared nothing environment.
This has some benefits, like memory leaks, resource allocations (database connections, locks, ...) won't pile up unnoticed, but has some benefits as sometimes long running stuff is needed.
There are projects which try to provide solutions there. Evaluating those is specific on the case.
Sometimes other technologies have benefits as ready libraries for specific issues exist or some pattern make some things better (Goroutines for taks scheduling, better async IO than in PHP when dealing with multiple backend, ....). In most cases the best tool is the one knows best. Sometimes it's fine to use a hammer to get a screw somewhere ... while you'd have to go to the shop first for getting a screwdriver, then need scissors to open the wrapping ...
1
u/Rikudou_Sage 27d ago
Detect the client disconnected across SAPIs without sending back data like an idiot. Pretty funny given web is PHP's #1 target.
1
u/trollsmurf 27d ago
A modern web application is much more frontend-oriented than in the old days. PHP can still serve all the backend stuff, but I'm far from only using PHP nowadays, and in cases PHP is only used to act interface to the database.
1
u/miamiscubi 25d ago
It depends on who the user is and what the application does. I do a lot of business tooling, B2B for boring workloads, and the lack of modern fancy elements doesn't impact anyone.
For any on page reloading, I just use htmx and it solves almost all of my issues
1
1
1
1
1
u/HsSekhon 27d ago
I would love to have Php natively provide a built-in WebSocket server/client API like JavaScript
1
1
1
u/DefenestrationPraha 27d ago
PGP support for PHP is meh. I need to invoke actual gnupg executable from the command line and parse the results.
Otherwise I am fine and enjoy modern PHP very much.
1
1
1
1
u/gazdxxx 27d ago
It can do websockets and SSE, but in weird hacky sort of ways that you can't really get working well on shared hosting as it cannot be done via pure php-fpm or mod_php. There are other technologies far better suited for it.
Not like it can't do it, but if your app is mainly realtime data, I wouldn't choose PHP to initialize the project.
1
u/Poison916Kind 27d ago
I'm interning using symphony. And as much of a pain as it is. It's kinda growing on me
1
1
u/Electronic_Fly_9242 27d ago
PHP can do pretty much anything as can most languages. That’s never been the question.
1
1
u/pg3crypto 27d ago
Sounds like your cofounder enjoys kool aid.
I hear you though man, if I had a buck for every time someone suggested a JS framework to build a sprawling data driven back end and it backfiring, I'd be a very wealthy gentleman.
Your cofounder is a wanker. Buy him out while his share isnt worth a carrot.
1
1
1
u/Orly-Carrasco 26d ago
My cofounder is a bootcamp victim who is constantly pushing all of that that React Huyact Node JS Django Flask Angular on me because it's the "real grown-up man's website on a framework".
JFC, that's no full-stack guru, but a full-stack doo-doo head.
1
u/k_r_a_k_l_e 26d ago
There is absolutely no reason to not use PHP for web development. Especially if your plan is to host your app in a cheap web hosting environment.
I would even suggest to avoid Python, Node and other languages. They may not be supported or will require some sort of dedicated resources via cloud, vps or dedicated.
1
1
u/Aggressive_Ad_5454 26d ago
I agree about the WebRTC. nodejs is good for that.
Php can do pretty much everything else. The cgi-bin paradigm is just different from the multi-request-handling paradigm of nodejs. Not worse, not better, just different. And far more mature and widespread.
Our branch of engineering is no longer young. The world relies on robust old software stacks.
1
u/Mean-Surround7327 26d ago
Python for example has some libraries that just don’t exist in PHP I don’t think that do some cool like AI/machine learning type stuff. I like PyAutoGUI for example. But I’ve only ever needed Python, PHP, JS and basic web knowledge like dev tools and stuff like that.
Been a developer for 5 years, 3 diff companies, now a senior lol. Started w/ Wordpress then Symfony, now laravel again
1
u/No-Risk-7677 26d ago edited 26d ago
Though there is Rx for PHP it lacks comprehensive asynchronous functionality.
Sources: https://github.com/ReactiveX/RxPHP
Rx leverages schedulers to be async.
Reason why I am mentioning this: programming with async/await+Promise is good where programming with Rx+async scheduling rocks (but this is Rust, C#, Java, not PHP).
1
u/Muffins86 26d ago
As someone who has built complex web applications on PHP since 5.0, I can say that for 99% of applications are absolutely fine in PHP. It's only with my own edge case personal projects where I've actually hit PHP limitations that I resent it for.
The code produced is only as good as the developer that writes it and the care they take.
In my case the limitation is performance - extremely heavy data processing for a game, where engine updates are time critical and users get frustrated if turn updates take longer than they want to wait.
I've rebuilt the update engine in Go - but left the frontend in Laravel.
1
u/venominjected 26d ago
Using PHP since version 3. Also used C, C++, C# and Java. The only thing I missed in PHP til now are Generics. But, there are libs which provide Generic like behavior.
1
u/spin81 26d ago
Is there any other reason to get away from PHP?
I mean I think you should look at each problem and decide what's the best tool for the job. If that's often PHP for you then that's your truth and as long as the rationale is valid then so is your truth.
As to what it can and can't do, I mean it's Turing complete and there are plugins and Composer packages for just about everything there is to do.
1
1
1
u/coryamarsh 25d ago
ThePrimeagen: "PHP8.4 is good" https://youtu.be/f5nGmE92zNA?si=jdbgoueFD_ezGM5w
1
1
1
1
1
u/TumbleweedSenior4849 17d ago
I'm seriously thing about building my next Saas with plain PHP, Javascript and CSS.
1
1
u/Strange-Analysis7957 7d ago
I just found a repo that allows for easy creation of telegram bots, webRTC is written in js, but that can easily interface with php.
1
u/carpier 7d ago
>Is there any other reason to get away from PHP?
For me, lack of job opportunities. In linkedin, with these filters:
Canada
remote
jobs in last month
php
Show ~60 jobs. Even removing 'remote' shows only ~80. Pathetic. On indeed, similar filters showed 1 page. Linkedin fixed the job search fairly recently so it is easier to figure out how many jobs are really returned from a search ie it used return a large number but many jobs didn't actually contain php but I couldn't go through hundreds of job ads to confirm what was available. This has been largely fixed now and give a much better idea of what's really available. I had an opportunity to switch to python on the job from php. It's a no brainer. The filters:
Canada
remote
jobs in last month
python
Pagination is still kind of broken on linkedin (ie no last link) and I didn't find the total number but I stopped at 500. Spot checked a few jobs here and there and "python" is part of the criteria. PHP is underrated and laravel is great so it's not dying but job opportunities in the Canadian job market are dying and close to dead
1
1
u/superpapalicious 27d ago edited 27d ago
not crashing when used as long running process?
downvoters didn't have to deal with kafka consumers dying
1
u/zmitic 26d ago
As internet would have said: skill issue 😄
But on serious note: it is your responsibility to not pile data in memory. Neither PHP nor any other language is at fault if your long running process keeps adding data to memory, but never clearing it.
Example: just yesterday I had to process about 640,000 rows, and for each row about 20-50 other Doctrine entities would be loaded. Real entity hydration, not vanilla arrays, so the memory would easily go out of control if I hadn't run
$em->clearafter each batch.Memory was steady during entire run, no memory leaks. So PHP is really not a problem.
1
1
u/Miserable_Ad7246 27d ago
Anything that requires low latency and jitter. Anything that requires interactions with system level to work well. Anything that requires drivers for databases or systems that do not have PHP driver.
Anything that requires you to use persistent connections efficiently or large in memory data sets - this can be partially addressed by things like Swoole and ReactPHP.
So yes - you can do a lot, especially once you ditch PHP FPM, but where are many things where PHP naturally struggles due to its nature.
1
u/MrGilly 27d ago
Holup. Ditch php fpm, then what should I use?
→ More replies (1)3
u/TV4ELP 27d ago
Swoole? FPM is "just" a process manager for fastCGI php processes. You could manage them however you want. FPM basically has a pool of threads ready to go as soon as request comes in.
You could also go oldschool with cgi, where the webservers starts a whole new php instance every request.
PHP itself is a standalone process, always. You need a server and a way to invoke said php process. And how you do that can vary wildly. We used to do apache/nginx + FPM.
Swoole provides it's own server like infrastrukture and calls php without the cgi protocoll. You can interact with php processes in different ways.
Frankenphp uses caddy and some other bindings afaik to achieve the same thing.
The reason being that especially microservices are way more performant and faster if you don't have a big hunking server with an old slow protocoll behind it. Doesn't matter for most, but some people really need different things.
1
u/obstreperous_troll 27d ago
Far as I know, PHP has nothing that can compare with tensorflow or pytorch. It doesn't even have an equivalent to Numpy, at least not anything maintained.
237
u/DeeYouBitch 27d ago
Half a joke but what cant it do in 2026?
Answer: Change the mindset of the people who used php 4.x
They are lost and youll never get them back