PHP – a look back, a look forward | Hacker News Reader

PHP – a look back, a look forward

blog.heroku.com

Heroku already supported PHP via buildpacks,i've been using heroku and php for years,it works very well(a bit expensive though),but I ended up reproducing git deployement on my own servers.

Heroku employee here. Yes there's been a PHP community buildpack for some time. I'm glad you got it working. Moving PHP to be officially sanctioned and "supported" by Heroku is subtle but significant:

We've hired a full time PHP owner. We've got PHP docs on the devcenter https://devcenter.heroku.com/articles/php-support and more importantly the features we document are "supported". If you've got problems with them we will provide application specific support (to the extent of supporting our docs and the platform). It also means that the experience will continue to get better as new features are added, and that PHP has a voice in the future of our platform.

PHP on Heroku has been a highly requested feature, and we're investing a good amount to make the experience a good one.

many many thanks for making this reality!

Product manager for the languages here at Heroku. You could absolutely deploy PHP on Heroku via buildpacks before as you can many other languages such as Go, Bash, etc. This support however makes it much more of a first class citizen working out of the box. Further the richness of this support with Composer for dependencies, HHVM, and proper support channels is fundamentally different than manually finding a buildpack to work for your needs.

The issue i think is managing PHP native extensions deployement.

Even if i require a package through Composer, there is no guarantee i'll have the proper native extension installed(think mongodb ,intl,apc...),w hereas with ruby or node,their respective package managers actually install all packages,including C/C++ ones.

How will you manage that in PHP?

It's probably my own lack of understanding, but I never really understood the benefit of PHP on Heroku -- it's so easy to setup a LEMP stack on somewhere like Linode, where I have full control and can still scale just as easy.

From the article: "In fact, for many modern PHP applications the notion of the LAMP stack seems limiting. Fortunately, PHP developers on Heroku can fearlessly take advantage of just about any technology they can imagine."

I'd argue that for many modern PHP applications it's PHP that's limiting. Modern PHP libraries and best practices are mindlessly copied from Java cargo-cult-style, without any of the benefits of Java, and without any understanding why Java does things in a certain way.

If PHP programmers were truly "fearless" about taking advantage of just about any technology, they really wouldn't be using PHP most of the time.

I'm a (semi-former) PHP programmer. I've really squeezed everything out of this shitty little language I could before opening my eyes and seeing other solutions. I see this as my mistake. And especially now, seeing "Modern PHP" turn into "a crappy Java clone", I had the choice of using a crappy Java clone or just using actual Java. So I eventually chose the latter (plus others, Erlang, C++, now Rust etc.).

PHP's only remaining benefit is the cheap shared hosts. It's a huge benefit for most sites, but that's it. The language itself is crap. So is everything around it.

"I've really squeezed everything out of this shitty little language"

Whenever PHP is mentioned people always jump to talking about the limits of the language and I'm curious what those limits were? I've worked on big and small code bases, large scale and small, and everything in between and haven't hit anything I'd call a "limit of the language" that we didn't just go right past without missing a beat. I do agree there are much better options out there now but based on a very different criteria which is why I'm doing what I can to learn many of them and move on from PHP.

Tbh, the only true limits I see in PHP are performance related. [e.g. I can write in Golang something that outperforms straight PHP+Accelerator or HHVM by a mile]

That and it was really designed as a fire-and-forget language so longer running processes have issues.

The reasons I can list are thousands. But to understand them it's really a matter of mindset. I can talk about long-running processes, threads, weak references, actor systems and so on, but most PHP developers would just phase out completely if I do this without sufficient background. At most they'll say something like "shared nothing!", like a tick, almost.

Because to PHP developers absolutely any problem fits into "state in MySQL and logic in PHP". Even with Memcache, or now with NoSQL stores like Redis, the mindset remains the same, just the API is different.

Someone once said "You can't connect the dots looking forward you can only connect them looking backwards."

To realize why PHP is shitty, you have to first get familiar with the larger landscape. Because if you don't, you'll believe every problem is fit for the golden hammer of MySQL+PHP until the end of your days, even if there are vastly superior solutions out there.

So, you're talking about design choices for which PHP (amongst many other languages) is the wrong tool, and your complaint is that... PHP is the wrong tool.

Therefor, PHP is shitty.

Yes, I'm not surprised people phase out when you start talking.

You see, turns out the design choices for which PHP is the wrong tool start to very seriously overlap the design choices that are best for most projects written in PHP these days.

But you can only know this if you are even aware of these design choices, and their benefits. PHP's architecture isn't the best paradigm for web development & "web scale" despite years of brainwashing in the PHP community. It's not the best by far.

So we have countless PHP apps shoved into the PHP paradigm for no better reason except that this is what PHP offers.

I've seen this happen a few times before with various technologies and I recognize the signs. Despite PHP supporters talk about PHP's bright future, the fact it's seriously starting to resemble a bad Java clone is only further moving us to the point people will start abandoning PHP in droves.

An example from the recent past which PHP devs might be familiar with is Flash. Flash's future was extremely bright mere year before it imploded very suddenly and "unexpectedly" to the uninitiated. The signs were there for years prior to that.

The problem is your logic is circular and you make generalized claims about how 'most PHP devs' do X.

No one here is saying PHP is a "golden hammer" to solve all problems. PHP is a tool for a specific problem domain and it solves problems within that domain effectively with certain cost/benefit characteristics.

> long-running processes No one here suggested you should be writing PHP daemons.

> threads Hint: That is what PHP-FPM is for.

> actor systems Actors are also generally long running processes.

etc.

> Because to PHP developers absolutely any problem fits into "state in MySQL and logic in PHP". Even with Memcache, or now with NoSQL stores like Redis, the mindset remains the same, just the API is different.

Every single CRUD application fits into this particular problem domain. Many PHP developers happen to work on CRUD applications, therefore many PHP developers first attempt to solve a problem in this way.

I've seen a large, well known IT company basically admit they did this [none of them were PHP devs] when they should have been using a very different architecture.

This is not a PHP problem, this is a mindset problem independent of the language used.

> No one here suggested you should be writing PHP daemons.

I agree with everything you've said and this statement isn't false in the scope of this thread. But I can't count how many times fellow PHP developers have suggested using PHP to write daemons and scripts that would be running on servers for weeks or months (or presumably even years) without restart or how much push back I received when I suggested using something better suited for it. But to your point none were proficient in other languages so it's only natural they'd try to figure out how to do it in the one they knew best.

Yes, if you're writing a multithreaded memory sensitive application (or really just any application in general that has performance as a primary objective) then PHP is not the right tool for the job.

It's not a golden hammer, it's just that most websites at their core are simple CRUD apps that initially don't need more than what PHP offers. When you do need to scale your PHP app to tackle these problems, there's no reason why you should limit your stack to PHP.

It's OK to not like PHP because it's not a beautiful language but I don't buy the argument that it's never useful.

Why the fuck does any post on PHP bring out the programming language hipsters who's semi-intellectual critiques actually have as much depth as the average "OMG, Nickelback sux!" comment on Reddit?

With this as the level of discourse in our industry, PHP or any other language is definitely not the problem...

I wouldnt consider Java crap first.Java is rigid,yes,but there is a reason why people can code these huge Java libraries. Because it's very structured.Now yes ,PHP is a flawed language.And in the age of the cloud where devs control their entire stack,there should be little reason to use PHP.

Except PHP is good at webpages,blogs,ecommerce and is mainly use with well known CMS that are not going to vanish overnight.

And frankly,when i see projects like Doctrine or Symonfy,which are bloated yes,yet powerfull, i'm amazed by what devs write in this language.

I didn't call Java crap. I edited the post to make this more clear.

While I agree that the "truly fearless" would just use Java, PHP has been significantly enriched by adopting some of the structure/idioms from Java. (Partly the adoption of any structure, Java or not.)

Reply on news.ycombinator.com