As much as I dislike PHP as a language I am still insanely productive in it for dynamic websites. I enjoy being productive more then I enjoy using the latest languages/frameworks.
I feel a bit bad for taking that cheap shot at PHP, to be honest. We're all adults, and you should use whatever makes you more productive. A good programmer can write maintainable code in any language.
However, "productive" and "latest frameworks/languages" is a bit of a false dichotomy.
I agree. But I have seen many programmers claim they will be more productive in language/framework X because its new.
As for cheap shots at PHP, I see PHP like the USA. Easy to take cheap shots at because its so large and runs so much. For all its faults/flaws its still pretty productive though.
> I agree. But I have seen many programmers claim they will be more productive in language/framework X because its new.
I've never seen that. I've seen many programmers claim that they will be more productive in new language/framework X because it includes a combination of features A, B, and C that aren't found together in other languages/framewors, but never simply because the language/framework is new.
The closest I've seen to the "because its new" thing is "because it doesn't have the accumulated cruft of framework Z", but while that may be related to newness, its still about features, rather than newness alone.
> Don't get me wrong, i'm all for new technology but bleeding edge on new projects can be a recipe for failure most of the time.
That's a fairly good reason for bleeding edge to be used as one track of a dual- (or multi-) track project which includes a short-turn-around, low-risk, low-reward track and one (or more) higher-risk, high-reward, longer-turnaround track.
This is equally true regardless of whether the project is "new".
Also note that there are a few more sophisticated PHP buildpacks contributed by Heroku users. Here's a good example that uses nginx for the web server and Composer for dependency management: https://github.com/iphoting/heroku-buildpack-php-Tyler/
Headline roughly translates to "we're willing to pay the perpetual maintenance cost of a new runtime because our existing runtimes aren't attracting enough users to justify the product", and the reasons for that cannot be fixed by adding yet another layer of lipstick to a pig.
Having worked on 7k+ reqs/sec sites on App Engine I can expand on this in great depth, but please google my comment history before making me write another essay!
> Headline roughly translates to "we're willing to pay the perpetual maintenance cost of a new runtime because our existing runtimes aren't attracting enough users to justify the product"
No, it doesn't. You may interpret it that way, but that's not a translation, that's your unsupported ascription of a motive.
It would be at least as justifiable an interpretation to say that this is a sign that the AppEngine platform has matured as a standalone product (rather than just a way to derive some incidental revenue at low cost from infrastructure Google has to have to support their core services) that they are getting around to supporting languages with heavy market demand but little internal traction in Google, rather than what is internally-useful to Google.
I'm sure they verified before making this decision that the income from these new PHP customers will surpass the maintenance cost. Also consider that this decision may not even affect Google's costs, because they have enough maintenance engineers idling at any given time to assign to App Engine PHP maintenance.
There also seems to be a dearth of good FOSS CMS's for AppEngine, which would otherwise be a great platform for that.
A WordPress port might also make a strong full service option for SMB's self-hosting their public corporate site on Word Press but using Google Apps for email and corporate infrastructure. Now they can put it all on the same P/IaaS.
Well if Google was following their GAE issue list then it will most likely be PHP (#1 3274 stars) followed by Perl (#2 2246 stars) and then Ruby (#3 2162 stars).
In the moments between the time I saw this and the time I saw that it was almost certainly PHP, I was hoping for JavaScript, with Ruby as a close second preference.
I can see why PHP makes sense, though, even though I have zero interest.
Do it in 30 seconds:
Now enjoy your insanely simple + free PHP hosting. I was pretty excited and surprised when I discovered this.