Google Compute Engine available for everyone, App Engine adds PHP
googlecloudplatform.blogspot.com
googlecloudplatform.blogspot.com
I think adding PHP is a strategically smart move by Google to get more people using their cloud platform. Soon there will be new billing relationships signed off by thousands of businesses to host basic apps and WordPress installations. Assuming customers have positive initial experiences with Google's PHP hosting, it will become easier for Google to upsell those businesses to add premium cloud features for more advanced applications over the coming years.
It's about time AWS had some serious competition.
Hah, yeah, okay, sure.
https://code.google.com/p/googleappengine/issues/detail?id=1...
Many hosting providers only support it because it's popular.
At no point in this equation does the relative merits of the language itself factor in.
When using PHP, a lot of the basic data structure transforms are implemented in the core language. You can integrate simple server side functionality into a static HTML page in just a few minutes, and it will work on 99%+ of hosting providers, and requires no fees and no tools.
For pedantic hackers like us, sure, it's garbage, but for the average person that just wants to get things done, it is pure gold.
Also, WordPress, while the biggest POS in almost every possible way, has a vast community of users, designers, plugin makers, and a marketplace for various extensions and themes.
Google just opened up a huge chunk of the web app / CMS market.
I disagree. The developers of Wordpress are not "the average person". There are too many production sites that run on PHP to say it's garbage.
I mean nobody in the almost literal sense. Stack Overflow serves as a rough barometer of popularity and either Symfony users have no questions, use another support platform, or they don't make up a significant population.
The #1 problem with the PHP community is it's complete anarchy and filled with people that should not be developing web apps, or at least should not be developing the way they're going about it.
Maybe Symfony could fix that, but there's a lot of work to be done here.
I am specifically talking about Symfony2, by the way.
A great number of frameworks and CMSs are using Symfony2 components. Two popular ones are the http-kernel and http-foundation components.
Drupal is integrating several Symfony2 components.
Composer, the PHP package manager that has taken the community by storm, is using Symfony components.
eZ publish is integrating several Symfony2 components.
Joomla! adopted YAML, using a Symfony2 component.
Stating that Symfony2 is not widely used simply tells me you're not keeping up with the PHP community - which would be fine if you're not a PHP developer, but makes your statement not trustworthy.
edit: PHPUnit, the defacto standard PHP unit testing framework, also uses Symfony2's YAML component.
I can go on.
Nobody uses Drupal, or eZ Publish or Joomla. They just don't. There's good reasons for this, notably these are some really obnoxious platforms to build for, but that aside their impact on the PHP world at large is inconsequential.
PHP, by and large, consists of people slamming together applications from the ground up the same way they built them in the 1990s. It shouldn't be this way, and people should fix it through education and outreach, but I really don't see that happening on the scale that's required.
Also, if you think even a quarter of the PHP devs out there even know what a unit testing framework is, you're more of an optimist than I am.
You could probably build a competing CMS in, say Laravel 4, replace the plugin system with Composer packages or something similar, use Twig and PDO out of the box, and have a much more elegant and modern system that probably almost no one would use, unless the user experience was just as brainless as it is with Wordpress.
Which is also one reason why, I think, despite all the arguments in their favor, static site generators (which do get mentioned now and then as an alternative to WP) still have a while to go before they're ready for mainstream use. It's not enough that it's well coded, it has to be easy too, and easy wins out over pretty every time.
WordPress is being pushed only because the majority of web developers can tinker with PHP only.
I think you're forgetting that most of the people who use Wordpress aren't web developers at all, and most of the 'web developers' who use Wordpress probably can't code much, either, because they won't need to. The ease of the Wordpress install is something they advertise. Once you ever have to touch the code, yes, it's a nightmare, even if you're inured to the horrors of php code. Most 'web development' jobs with Wordpress involve the install, setting up themes, maybe editing the css and installing plugins (because even that is still more arcane than some non-technical bloggers and people want to deal with.)
The "low bar for entry" for PHP comes up as an epithet now and again, but if you're trying to increase the adoption of your particular language, having an application the plebs can run isn't necessarily a bad thing. Does anything similar exist in the Python or Ruby worlds yet, for which someone wouldn't be expected to know how to use a terminal, or handle git?
It is, I think, almost entirely down to being less of a hassle than anything else out there, and especially less of a hassle than anything not written in PHP. Call it laziness if you will, and I wouldn't entirely disagree with you.
PHP is like Perl blended with C and a whole lot of confusion.
Frameworks have made it "better" like ketchup improves the quality of prison food, but it's still terrible on the whole.
No, it does mean it's good. You're comparing opinion (everybody has one) with actual hard real world results (tons of major sites with million hits running on Wordpress and around 15% of the web too).
Inertia is powerful.
Though, to be honest, I don't think that using Play (today) or Rails/Django (yesterday) is sufficiently less productive to merit the technical debt you almost certainly will incur starting with a PHP stack. (And I am an ex-PHP person, to the point of hacking around in PHP core...that's a few months I'd love to have back.)
Facebook's former CTO has said that the only reason Facebook is still on PHP still today is legacy. It wouldn't be written in PHP if it were started today.
PHP once was the right tool for the job, but those years have passed. We have many better options now.
A sane engineer considers the full pictures before picking a solution rather than pick their pet languages just because it's nice and clean.
Wikipedia's Mediawiki software is awful, and serves as a great example of how not to build an application. It makes WordPress look like a precision engineered Swiss watch.
Yahoo uses PHP because, like Facebook, they could make FORTRAN work in production if they wanted to.
A sane engineer don't pick technology based on what is most theoretically pure, but based on what can deliver on the requirements on time and on budget.
If you are building a simple CRUD style application, for example, there's likely nothing in your technical requirements that precludes PHP in any way. Then the question turns to ease of deployment and maintenance, operational costs, cost and availability of developer time, and there PHP tends to score quite well, not least because there's a huge pool of relatively skilled engineers that know it.
I personally prefer Ruby and don't like writing PHP at all, but I'd be a horrible engineer if I wrote it off in situations, where, e.g., it is hard to hire Ruby developers at a reasonable price, or there's a lot of existing PHP knowledge within a team that is already in place.
If you can find RoR developers, they are not cheap. If you're building a v1 product on a limited budget, and don't want to spend 80 hours per week writing it yourself, PHP is an excellent choice.
Having to read the code with a clothespin on your nose is a small price to pay.
Are there automated deployment tools written in PHP for PHP applications? I mean ones that can be taken seriously.
What optimization options do you have for PHP? What latitude do you have with hosting? If you're not Facebook, writing your own PHP engine, you're going to be stuck with one of a few that are generally crappy.
Cost and developer time are non-factors since the time you'd need to learn PHP is probably higher than other languages that make more sense and aren't filled with anachronisms you will spend half your time working around.
You can train someone up in Ruby on Rails in two weeks. Django or Node would take about double that time, but only because the platforms aren't by default as feature complete and the tooling will vary from project to project.
"Cost and developer time are non-factors"
Bro, do you even startup?
His point was that learning PHP properly with all the shenanigans takes at least as much as time as learning a well thought out environment.
It's not snobbery. It's called doing your job like a professional. This is harder in PHP than it is in other languages.
The only language more cantankerous and difficult than PHP is C. Learning PHP properly is hard. There are hundreds of little things you will have to be very careful about because they are easy to get wrong and the cost of failure can be enormous.
If you can't see this, you're basically a PHP snob. You're holding your pet language to a different standard than others.
I detest PHP from a language writers standpoint. Programming language design is a hobby of mine, and I am a real snob about programming languages from a personal preference point of view, and PHP certainly does not measure up.
But I don't let my pet ideas about what a programming language should be like stop me from doing my job, which is to ensure we have an environment and team where we can get projects in on time and on budget with a staff that is both skilled enough and cost effective enough to keep us profitable. Is it possible to do this with Ruby? Sure. But the dynamics are very different, and the potential customers tend to be quite different.
I've written web services in a number of languages, including C and C++, and been responsible for systems in a mix of PHP and Perl that handled ~$50 million worth of card payments and invoicing, and I've developed Ruby based systems and hybrid PHP - Ruby - C++ stacks. When I can justify picking Ruby, I do, because I love the language. But I refuse to pick Ruby just because I personally like it and it has a higher coolness factor in the face of economics where it doesn't make sense, such as when there's installed bases or teams that are already skilled at PHP. It'd be irresponsible.
You don't have to use those things, but they are there if you want them, just like they are in other languages. Neither Python nor Ruby enforce unit test or parameterized SQL requirements.
I don't like the language itself, but I do like the myriad benefits it brings. The only pet language I hold to a different standard is Perl.
I agree that if you already know another platform there's no reason to switch to PHP, but similarly i've not seen much reason to switch away from PHP, aside from personal preference in language syntax.
Contentious. The VM itself is, but there are many functions implemented in C. Whether it'll be fast or slow for your application is not necessarily immediately obvious.
If you think that, you don't have much real world experience.
> Are there automated deployment tools written in PHP for PHP applications? I mean ones that can be taken seriously.
Why do you need a deployment tool written in PHP for PHP applications? Are you serious? It's a ridiculous proposition to care that much about the language the deployment system is written in. What I care about is what benefits it brings me.
Where I am now we have our own deployment system, btw. - we operate a private multi-tenant cloud specifically tuned to the type of workloads our customers have, at a cost ~1/3 of what it'd cost us to host our current infrastructure somewhere like EC2 with equivalent redundancy and performance. That is including the development and maintenance costs for our in-house tools. As part of that we have a rapidly improving set of deployment tools. Handling deployment of PHP was pretty much the simplest part of that system.
> What optimization options do you have for PHP? What latitude do you have with hosting?
Are you for real? I love Ruby. I'm working on a Ruby compiler as a hobby. But scaling PHP is trivial compared to RoR. I don't need optimization options for PHP - one of our clients processes restaurant bookings worth 50 million pounds a year via a setup that consumes ~30% of CPU resources on two frontend servers with a combined leasing cost of ~1000 GBP/year. The vast majority of their cost (their total yearly cost for their internet presence is about 3 orders of magnitude above the cost of the servers hosting the PHP code) for this system is marketing, support, power and bandwidth in that order. Cost of the frontends that PHP run on comes at the very bottom - it's a rounding error. If we needed more frontend capacity? We'd add another couple servers like that, and it's still be <1% of their cost.
What costs us money on the hardware side is database servers and network infrastructure. Web frontends for typical simple web apps are cheap. Sure, there are exceptions (but as much as I love Ruby, RoR is certainly not going to save you scalability grief in the cases where scaling PHP becomes hard or costly).
> If you're not Facebook, writing your own PHP engine, you're going to be stuck with one of a few that are generally crappy.
If you're not Facebook, there's no compelling reason to write your PHP engine as PHP is fast enough for pretty much anything you throw at it until you're in a situation where you have thousands of servers, where shaving a few percent off here and there starts creating large savings.
A vanishingly small number of companies ever reach that scale - optimising for that in advance is lunacy, and most "cleaner" languages does not provide a better starting point in that respect. Ruby, for example, is far more costly to scale.
> Cost and developer time are non-factors since the time you'd need to learn PHP is probably higher than other languages that make more sense and aren't filled with anachronisms you will spend half your time working around.
Spoken as someone who doesn't know the market. I have a steady supply of qualified PHP staff. In fact, we have recruiters hounding us every day with cheap candidates that know PHP. Ruby? Rarely, if ever. Those who know Ruby well enough have an easy time finding better paid jobs.
> You can train someone up in Ruby on Rails in two weeks
Bullshit. You can get a senior developers that is already expensive to relative beginner level in that amount of time. Or you can hire a PHP developer that is already skilled at ~60% of the cost.
I've seen "RoR developers" with two weeks experience, and what they produce is not pretty, and certainly does not result in a good ROI compared to more pragmatic solutions. I'm all for using Ruby if/when you have a good team of Ruby developers, but you then also need to realize that you have an expensive team. It makes sense when your team is highly experienced and rapid turnaround is more important than keeping the cost down, or if your personal satisfaction is more important to you than the cost - both can be perfectly valid reasons. If I were to start a new company now, I'd pick Ruby myself. But I would do it because it is what I would prefer to work with, not out of any illusion it's currently a cheap choice.
Yes PHP has a lot of bad parts. But its good parts are really really good.
Most hosting providers dont allow serious php development anyway , so it makes little difference. You need a vps or a PAAS to do serious PHP development , like any other solution out there.
I love python and ruby. But I really miss type hinting everytime i use one of these.
... except for "easy to deploy", which is a merit.
* Cheap to deploy
* Easy to find programmers to help you
* Affordable programmers
* Code is easy to read for non-programmers who understand HTML
* Ton of free code available to reuse
Inconsistency, poorly thought out OO, lack of purity, and disdain by hipsters are a small price to pay for those merits.
"Hating PHP? That's so mainstream. Personally, I'm hating on Haskell and NodeJS."
So I would say you should learn something in addition to PHP so that you bring more value where you go.
Put another way: don't be a PHP programmer. Be a programmer. Then, use the right tool for the job based on the constraints given to you. If that ends up being PHP, you'll still be paid more to do it.
Secondly, the reason some programmers are more expensive than others is because they're more efficient.
Who would you rather have? Six PHP programmers that flail away for a month and ship a buggy but usable application? Or maybe two Ruby or Python developers that ship a unit-tested, well engineered application?
The two developers will cost you about the same as the six others if they're top-notch, but they will not make the same mistakes and they will not stumble into every potential pitfall along the way to the solution.
Wielding a master's sword does not a swordmaster make. Surely you've seen enough RoR and Django projects to know that.
Some people will say that something not written in a strongly typed language is not well engineered. If it's not compiled, it's not efficient. This is just programming snobbery. For what it's worth, I was that kid in high school, except back then it was Perl. That's how I learned. Something that makes it even easier? That just creates more programmers. Without shitty programmers, we'd be paid a lot less.
I talk a lot of smack about PHP and JavaScript, but these terrible languages have brought more people to programming than any other languages.
Remember, both PHP and JavaScript were serious tar-pits ten years ago.
JavaScript has made enormous strides in that time, the cultural shift is unbelievable. People went from writing absolutely terrible client-side code, to using frameworks (Moo, Scriptaculous at first, later jQuery, RequireJS) to using it server-side for serious applications. It's gone from complete anarchy to highly civilized. There's some things JavaScript does very well now, and in an elegant way mostly free of quirky tradition and/or obnoxious anachronisms.
Meanwhile PHP has only degraded. It's improved, technically, but the community is now hyper-fragmented. Best practices are routinely ignored. Frameworks don't inter-operate even on the most basic level. There's no leadership. There's opposition to even the most obvious improvements to PHP, like deprecating components that are doing nothing but holding PHP back. Killing off `mysql_query`, for example, is absolutely imperative, but it's going to be a bitter fight.
braces for downvotes (I did try to be fairly balanced, to be fair)
[1]: the wisdom of doing this left to the reader.
Thought: ah, my sibling commenter managed to put it better than me (and less controversially).
They're both awful languages that are popular because amauteur programmers can easily get started and churn apps. There is just as much, if not more, horribly written spaghetti JavaScript out there, even by Rails and Python developers, as there is horrible PHP code.
The only reason people don't belittle JavaScript (as much) is because there are no other options. If there were, I think JavaScript would easily be the next PHP (and for good reason).
I think once people know how to use JavaScript appropriately and uses it's strengths then it's a much better language. Back in the day I found JavaScript weird and messy but that was partly how I used it. The prototype pattern is extremely powerful and JavaScript is a multi-paradigm language, which is great. OOP or Functional, it's your choice.
With the rise of really good front-end frameworks (they're getting better), the quality of JavaScript applications is getting better and better and Node.js has also done a really good job at boosting JavaScripts rep.
I do think the standards body is greatly flawed and all the different browser implementations are increasingly frustrating. The ability to use new features is extremely little, unless you use JavaScript as an embedded language in another application (i.e HTML5 App in a native context).
I don't think JavaScript will be the next PHP.
JavaScript isn't a great language, but it's OK. Maybe "awful", but lots of languages are.
PHP, on the other hand, is in a class of its own, far worse than JavaScript or any other mainstream language I've experienced.
For example, javascript at its core has a string type that is treated like an array of characters in proper unicode, with a sane extensible method-based string api. PHP at its core by contrast only knows byte arrays and its string handling (global!) functions are basically useless for dealing with unicode (there's mbstring and intl, but too many people don't use those).
Wikipedia, Facebook, MailChimp, WordPress, tons more -- they all load fast and are hardly ever down.
You can argue all day about the fine details of programming languages, but PHP is popular for good reasons.
The only thing I would consider using App Engine for at this point would be a school project or something.
If agility matters, I've not found anything that beats it. You might not want your service running on there as you scale, but it's enough to get a few thousand users onboarded as a proof of concept.
If you want a proof of concept and you're not concerned about getting the scalability, why not run on a single server?
[1] https://developers.google.com/appengine/articles/sharding_co...
Well, except that there is an open-source alternative implementation of App Engine that you can run anywhere you want. [1] Which kind of ruins the whole "no way to failover from App Engine to some other platform" argument, even for apps built the "App Engine Way".
To be fair, AppScale is a separate entity and therefore there's no guarantee that they will keep up with GAE API's, API bugs, and/or quirks. These are obviously things out of their control, but I'm saying this because there's still no guarantee of a 1:1 replacement if you need to move away.
I see PHP as a growing and evolving object-oriented programming language. I see it as a language to which design patterns can be applied, for which structured designs can be applied, and which has improved which each major release.
I also am keenly aware that it has a legacy and a reputation of being something else, a rapid prototyping environment for programmers that don't have exposure to other systems, and take it as a glorified template language for HTML.
But I don't see it that way, I look at projects like http://reactphp.org/ which brings Node.js-style evented programming, native support for ZMQ and websocket, and makes PHP a great language for developing web workers. (Though with some caveats, for instance, I use PHP for my own application because it's dependent on the cpanel xmlapi which is provided in PHP). But that really is my point, you can abstract PHP from it's humble web roots and be a productive programmer in it.
I wonder how the performance is -- will they support common cache plugins? If not, I wonder if stock wordpress on GAE will be able to withstand getting frontpage'd on HN/Reddit
Edit: Unfortunately, as there is no CloudSQL free tier, there's no way to test it out without paying a small amount.
its
I apologize that I have not closely familiarized myself with Google Cloud SQL. Is it really API compatible with MySQL, or are there limitation that one is bound to run into when one starts adding plugins etc.?
I also don't quite understand (not having tried it out yet, obviously) how you'll handle static files (images, etc.) uploaded via the Wordpress "media" feature. Is GAE able to support that?
Anyhow, congratulations on the launch. I'm not a huge fan of PHP myself but I frequently find myself having to use it (e.g. to host a Wordpress site!) so this is really an interesting avenue for me to explore.
https://developers.google.com/appengine/docs/php/googlestora...
We're working with a couple of Wordpress developers on a plugin to integrate Wordpress media uploads with Google Cloud Storage.
The App Engine has mades some decisions that seem to be contradictory. At one end, they drastically increased their prices and sent a signal the GAE was an enterprise-focused platform. Now, they're releasing PHP so people can host blogs on it. Really? You want to compete with $5-6/month wordpress hosting solutions. Who is running the show there?
It's not something I want, but apparently there are quite a few people who do.
Also what people request and what google's vision is are two different things. Who are they targeting with this PHP stuff. Yes sure, for free-tier stuff, I'm sure lots of kids playing around with PHP would love to have a sand-box to play around. But this move seems inconsistent with their prior action that signaled a move toward enterprise sales.
Also, it feels like one side of google is not talking with the other side. They're building a whole application scripting system hosted on google Drive to work with google apps, etc. Why not provide the javascript on GAE to allow further application development and integration.
To be honest, this feels like: Oh shit! Google I/O is coming up and we need to have something to show than a vision of providing cloud-based computing solution that fits within their big vision.
Google's vision is "developers deploying scalable apps on App Engine". Being developer-friendly is good for that.
> Who are they targeting with this PHP stuff.
Existing PHP devs. Which is a lot of devs.
> Yes sure, for free-tier stuff, I'm sure lots of kids playing around with PHP would love to have a sand-box to play around.
Lots of apps that end up making money use PHP.
> But this move seems inconsistent with their prior action that signaled a move toward enterprise sales.
Enterprise is an area that Google would like to get their Cloud Platform, including App Engine, more sales in, but its never been anywhere close to their sole target for it.
> They're building a whole application scripting system hosted on google Drive to work with google apps, etc.
"Building"? Apps Script has been around a long time (longer than Drive itself; maybe longer than App Engine.)
> Why not provide the javascript on GAE to allow further application development and integration.
Javascript on GAE would make a lot of sense, too (especially in light of App Script and Google's work on V8 and the emerging popularity of Node.) So would Dart-on-GAE. I wouldn't be surprised if either (or both) of those happened. But the fact that it makes sense doesn't make PHP make any less sense.
> To be honest, this feels like: Oh shit! Google I/O is coming up and we need to have something to show
App Engine PHP wasn't even the big Cloud Platform announcement tied to I/O; general availability of the Compute Engine IaaS (and the associated new pricing and instance types for Clound Engine) was the big Cloud Platform news.
> than a vision of providing cloud-based computing solution that fits within their big vision.
Google's big vision for cloud-based computing is, well, big. It includes more than one kind of solution, for more than one market segment.
Your attitude is ridiculously arrogant.
PHP powers most non-corporate website on the web. The wast majority of wikis, blogs and forums. You know, things that are used for actual communication and knowledge sharing by millions of people.
Either case, help me understand why PHP was a better choice vs. Javascript? If the question is barrier to entry. Then javascript should have the lowest. Anyone doing any web development needs to do something in HTML/Javascript/CSS.
Additionally you could have made the case for further integration with your other services like App Scripts. Aren't google team talk to each other?
I personally would have rather seen Google focus on Go and remove "experimental" out of Go so people feel some amount of security developing and investing time building Go applications on GAE. Just my $.02!
What you can't do is run javascript server side. Given the unique requirements of server side javascript, and the fact that the single dominant implementation is maintained by a competitor in this exact space, it isn't a great fit.
Google already has a cloud based, server-side, javascript platform in Apps Script, and has purchased at least one company that operated a JavaScript PaaS, so its not like doing JavaScript serverside is out of Google's reach if they strategically wanted to do it.
I can see why, given the mass of PHP apps out there, PHP might be a priority for App Engine given what App Engine already supports, but I can't see JavaScript as having a significant barrier to practicality.
Slamming PHP is akin to slamming the x86 instruction set. It's besides the point. There are so many large "apps" that effectively use PHP as asm; we need to have a solution for customers that want to run open source CMS:es and CRM:s, for example, and this is all Wordpress, Drupal, SugarCRM, MediaWiki, Joomla etc.
And there are a LOT of startup companies building in PHP, believe it or not. PHP on the server is akin to Javascript on the client. You can argue that Erlang or Go is better, fine, but the reality is that most web sites are PHP. And similar to what happened with V8, there is a significant industry effort in just accepting this and making PHP run faster and better. We don't want you to compare GAE/PHP with GAE/language_X. You should compare GAE/PHP with [other platform]/PHP, and see if you like what we've done. And we're doing some cool stuff with it. We are working to support PHP code better than any alternative. We expect PHP developers to love it. But we're not doing it in order to advocate (or not advocate) PHP per se. You don't like PHP? Then move along, there's nothing to see here.
And as for the "small $5-6 dollar sites" (or free), that doesn't matter. Many of the apps running on GAE are within the free tier, which is one of the great things about the platform. So that's not news. Part of the GAE vision has always been to offer a place on the web to run small web apps for free.
Is there a MySQL-like solution on GAE as well?
Also, anyone who is doing javascript is probably avoiding java and doesn't want to figure out how to put the right files together to deploy such an application.
* Till its gets some traction, whereupon we will either jack up prices by 100% or more, or till some bigshot at Google kills it saying its not 'strategically aligned'.
I tried to address it back at the time, I invite you to read my thoughts again: https://plus.sandbox.google.com/110401818717224273095/posts/... and happy to debate again. But please read it first.
GAE at the time was running as an experimental/beta product. There was no support, there was no SLA, and there was no deprecation policy. When a product is experimental or beta, eventually the time comes around when we need to look at next steps.
We concluded that the pricing was insanely low at the time and did not make for a viable long-term product. And when we talked to customers, they absolutely didn't want us to discontinue the product, but instead they wanted us to invest in it and provide support.
So that's what we decided to do. In working with customers, we determined that (after reasonable optimizations), the vast majority of apps would experience 2-5x increase in bills. Obviously we lost some customers because of this, but much fewer than you think, and mostly (but not always) because they were simply architected in ways that badly matched GAE, or had business models that assumed a cost-of-operations that was unrealistic (either on GAE or anywhere else), and that we had in effect been subsidizing.
GAE targets being the "best" option, including cost - but you need to include the entire cost, and factor in ease of use, SRE operations, durability, scalability, etc. We're happy to duke it out with any apples-to-apples comparison for total cost of ownership.
An excerpt:
> I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.
> You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.
> You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.
> You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.
> And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.
> Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.
> That’s what’s wrong with PHP.
I will refer you to an even better quote: 'Software engineers are becoming like "photographers". They spend so much time arguing over the right lens type, focal length, camera body, flash and other sets of tools until they discover they've already missed their opportunity at taking some great shots. Software devs are now doing the same thing, arguing over the tools they use, wasting precious time instead of getting work done.'
The linked article specifically does explain why PHP is bad, and it does it by providing literally hundreds of specific examples. It's a really impressive essay.
Even though it's common, I don't think referring to programming languages as tools is actually accurate. A programming language is more like a building material. And this is an important distinction.
Let's look at scenario.
Say Fred hired Bob to write a program for him. Bob decides to use PHP. After finishing his work, Bob moves on to other projects. A while later, Fred realizes he wants some changes made to his program. So he hires George. George can't make changes to the program in Haskell. He has to modify the PHP source.
The reason I bring this up is that the choice of programming language is important, and is not the same as the choice of tools (e.g. your text editor).
You can build a house out of paper mache, but chances are you'll end up regretting it.
I've spent the last 8 months writing a fairly complex application as a REST API entirely in PHP and I can't say that I've ever run into any weird scenarios where I think to myself, "Damn, this is sure it like have a hammer but with claws on both sides."
My code is very OOP relying heavily on my own classes and not quite as much on the built-in PHP functions. I have also found that when I need to do something odd that there's usually a pre-built function already in PHP for doing it.
So if you're going to bash PHP at least throw out some actual PHP code and explain why it's bad (and make sure to point out that there's no other really good way to do it in PHP using you're own classes/methods).
There's lots of example code, inline, but much of the article is about missing/broken features and artifacts of the design that make it unfriendly to wetware.
php > $x = array("a" => 1, "b" => 2);
php > echo $x["a"] . "\n";
1
php > echo array("a" => 1, "b" => 2)["a"] . "\n";
PHP Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1
When I got into web dev I spent 2 years developing in PHP before moving on. My programs worked fine, eventually, and some were even well-written. I'm sure yours are too. That doesn't make PHP any less of a mess. But I never understood until I moved on to Ruby and Python and beyond just what a mess it was.
I'm also slightly alarmed that the PHP examples use htmlspecialchars and nothing else. The Python documentation has a whole section on templating with an example autoescaping setup using Jinja2.
So many new "me too" clouds, Azure, Rackspace, HP, even Oracle, and now Google.
Here is the run down on the runtime services available in the Java SDK (I think that it and Python are the most complete, not everything is available for Go last I checked): https://developers.google.com/appengine/docs/java/apis
This is a good supplement: https://developers.google.com/appengine/tools_tips
So queues and email are in, messaging might be served by Google Cloud Messaging or the recently announced Trello partnership. I don't think anything quite like CloudWatch or Route53 is available.
I think of GAE as more like Heroku + add-ons than a straight AWS competitor so I wouldn't expect them to be entirely equivalent. On the other hand more control over the runtime lets them offer things that are entirely out of scope for AWS (channels).
As far as updates, the blog shows the the SDK gets new features fairly frequently: http://googlecloudplatform.blogspot.com/
Yeah, I have no intention of using GAE, they don't support haskell anyways. GCE is the direct equivalent of EC2, they have an EBS and S3 equivalent as well. I that core puts them in a pretty direct competitor position.
I always liked what Google was getting at with GAE i.e. a simpler, more cohesive AWS. But it just doesn't seem like Google has its heart in it. And we all know what happens to products like that at Google.
Do try to keep up: https://code.google.com/p/googleappengine/wiki/SdkReleaseNot...