Hacker News new | past | comments | ask | show | jobs | submit login
Google Compute Engine available for everyone, App Engine adds PHP (googlecloudplatform.blogspot.com)
184 points by zafirk on May 15, 2013 | hide | past | web | favorite | 157 comments

I see a lot of people on here wondering why Google would just now add support to PHP. I don't work for Google, but I used to work at Microsoft. When Azure launched it tried to "leapfrog" the other cloud vendors by offering only Platform as a Service (PaaS). It offered superior benefits like high-reliability and geographic redundancy. Though, that was met with limited adoption. Why? Well, one of the major reasons was because it would require developers to write new apps or rewrite their existing apps from the ground up very specific to how Azure wants you to write it. This takes a lot of effort from a very specialized skillset, thus very expensive. Also, since you're writing it for the Azure platform, should you decide to switch to another provider, you'd have to rewrite your app again! What if you had a bad experience with customer support or billing? You'd basically be stuck. So Azure has since started offering Infrastructure as a Service (IaaS) options, which has far lower switching costs. This has had much greater traction and builds an ongoing relationship with customers. The customers become more familiar with the Azure platform and support offerings. If they feel good about their IaaS experience, they will consider learning some of the premium features and leverage them when they update their existing apps.

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.

In related news, Google also just dropped Drive pricing to exactly 50% that of Dropbox. Looks like they're trying to monetize all that huge capacity they have floating around.

It's about time AWS had some serious competition.

In related news Amazon Cloud Drive still costs less per GB than Google Drive. AWS is also years ahead of GCE in terms of features and customer support and has been dropping prices regularly for years. GCE doesn't bring anything new that Rackspace, Azure, HP, Oracle etc. aren't already providing. GCE is likely to be as effective against AWS as Google+ was against Facebook...

It's about time AWS had some serious competition.

Hah, yeah, okay, sure.

LOL at adding PHP support to app engine almost 5 years later. PHP gets a lot of bashing but you can't deny its popularity, as evidenced by the number of stars.


PHP is only popular because many hosting providers support it.

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.

PHP is popular because it's incredibly easy to get started for someone used to doing things with HTML. An HTML page can be renamed to .php, and that is a valid PHP page. For someone trying to go from HTML/CSS to the server side, PHP presents the path of least resistance.

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.

> 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.

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.

Wordpress is garbage. Just because there are a lot of production sites built or using Wordpress doesn't mean it's good. Wordpress is popular because of it's community, use of PHP which allows you to host it on many providers, and a ton of themes and plugins. Wordpress is probably the worst spaghetti code I've ever seen (we'll, close).

>Wordpress is garbage. Just because there are a lot of production sites built or using Wordpress doesn't mean it's good.

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).

Most of the arguments are biased opinions and can't really be defended. But... if you don't like wordpress, why not assess projects such as Symfony2 or Drupal?

Because quality projects like symphony Symfony 2 does not fit into his works view of php.

If Symfony is so amazing, why does nobody use it?

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.

You'd be very incorrect if you thought no one was using Symfony2.

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.

It's like Symfony2 is a gourmet restaurant in a town that finds McDonald's too expensive.

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.

Maybe. But the fact is PHP as a language is messy, albeit some frameworks have made it better (i.e Laravel). I'm assessing Wordpress because of it's praise by many people when it's not well built (have you looked at the codebase?). Just look at the author and history of PHP, the author hates computer science, and it was derived from Perl as a templating engine, not something I'd hold as quality. Nonetheless frameworks have made it better but I still feel the platform is broken and often attributed with newcomers to web development.

I think you would be hard pressed to find anyone praise Wordpress code if they've had to work with it, apart from actual contributors to the WP core of course. Wordpress is popular almost entirely because it's easy to deploy and has a vast ecosystem of plugins and themes which mostly just work.

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.

Using WordPress is not as brainless as you point it out to be. All software needs to be learned, and from my experience let me tell you WordPress is not always learnt well.

WordPress is being pushed only because the majority of web developers can tinker with PHP only.

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 was built by a guy who didn't even know he was building a programming language. He's quite honest about this.

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.

Because Symfony2 and Drupal are just different flavors of garbage, and Drupal is significantly less pleasant to work with than WordPress, which is about as pleasant to work with as an angry bear.

You put it very lightly. It is not pedantry or elitist hackers, it is computer science. A sane engineer with a little bit of experience would not start off with PHP to build anything at all.

Engineering is not computer science.

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.

Cost and availability of developer time is much more of a factor in platform choice than a lot of people think, especially engineers who don't have to worry about the business end.

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.

For the question "I want to build a web application", PHP is not the answer. It is the worst in nearly every category you cite.

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.

The framework benchmarks posted repeatedly here have shown PHP can hold its own performance-wise against ruby and python. PHP is not slow. PHP's per request model also makes it easy to build state-free front-end servers which you need in order to scale by throwing more hardware at the problem.

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.

> PHP is not slow.

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.

Software snobbery.

"Cost and developer time are non-factors"

Bro, do you even startup?

Don't quote and cut half of his sentence off. You tried to change the meaning substantially.

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.

His definition of properly is nothing but an ever moving goal post of software snobbery.

"Unit tests? SQL escaping? What are you? A snob?"

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.

What you miss is that I can source a dozen qualified PHP candidates in ten minutes just by searching my inbox for e-mails from recruiters I haven't yet deleted, that already know these things, and that charges substantially less than equivalently skilled candidates in a lot of the languages we both might agree are more elegant, if I'd even find those candidates - contrary to PHP, I don't have recruiters beating down my door to place candidates that are skilled in Ruby, and when I've helped friends find candidates for Ruby work, it's always far harder, and they end up paying a lot.

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.

Where are you getting the notion that unit tests and parameterized SQL are difficult or not commonly used in PHP?

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.

> It is the worst in nearly every category you cite.

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.

So the apps I wrote in PHP are scientifically worse than the ones I wrote in Ruby? I had no idea!

Facebook. Wikipedia. Yahoo.

Facebook could write their stuff in COBOL and it wouldn't matter to anyone else. Remember MySpace? It was written in ColdFusion, so I guess ColdFusion is a great idea!

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.

pestaa's comment needs to be amended. It should read: "A sane engineer with a little bit of experience would not start off with PHP to build anything at all in 2013."

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.

We have many technically cleaner solutions, but in the real world other factors, such as ability to quickly hire sufficient number of reasonably priced developers, often means a lot more than technical purity.

A sane engineer considers the full pictures before picking a solution rather than pick their pet languages just because it's nice and clean.

Were either of the first two started by "a sane engineer with a bit of experience"?

Inertia is powerful.

Perfect is the enemy of good enough. Doesn't matter what your site is coded in if it isn't revenue positive/have funding/etc.

I'm not sure where you got that from my post.

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.)

Because no engineer out there use php to develop anything ? right ? those folks at dailymotion , (the only youtube real competitor that yahoo wanted to purchase ), they are such insane engineers using php... i bet you are better than them hey , what did you build that is famous and used by millions of people around the world ?

At no point in this equation does the relative merits of the language itself factor in.

... except for "easy to deploy", which is a merit.

* Easy to deploy

* 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.

You get what you pay for in the PHP world. You can hire some kid out of high-school to slap together some application in a weekend and pay them in beer, sure, but what will you get? The maintenance costs on this abomination will quickly consume any up-front savings.

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.

You're mixing technologies (PHP vs Ruby / Python) with types of programmers (inexperienced vs experienced).

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.

I've seen some screwed up Rails and Django projects, but the severity of the damage is never, ever, as bad as a bespoke PHP application. It's not even in the same league.

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.

... disdain by hipsters is a bonus in my book.

So you're a hipster, basically.

"Hating PHP? That's so mainstream. Personally, I'm hating on Haskell and NodeJS."

I plan to hate Python once I learn enough of it.

Significant whitespace.

So you're saying that, as a programmer, it's in my best interests to learn something other than PHP so I'll be less affordable...?

Depends on why you're a programmer. If you wish to optimize for compensation, by all means, learn as many different languages, platforms, and technologies as you can.

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.

Yet they didn't support it for years and now they are. I only found it funny because within the HN ecosystem you get the impression that it's really dying (rightfully so given the better options out there). Now another platform provider is supporting it, which will only increase its popularity according to your statements.

For many applications they require a CMS and PHP clearly owns the market space here with Wordpress and Drupal -- strategic in terms of driving growth and new business. We also believe that since App Engine was built with multitenancy in mind from day one that it's a more secure, hardened environment -- better for developers. Finally, and to my point above, the majority of the internet has been built with PHP whether folks like it or not. We want to bring the benefits of cloud to this large corpus of developers -- advancing computing rather than stagnating it.

PHP is popular because users know it is a good compromise between javaish stuffs ( type hinting in functions and methods , private,protected,public members, interfaces,and abstract classes ) and some whatever dynamic stuff out there ( dynamic , weak typing ) and some weird/functional stuffs ( pointers , closures , callbacks ).

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.

PHP has just mixed and matched a ton of different features from other languages without having consistency. For example, many of the core functions have different naming conventions and many of it's OOP features are after thoughts.

Popularity, yes. I'd argue it largely comes from amateurish developers, though. It can be used at scale, of course[1] but surely it's popularity is as a result of the hordes of amateur developers and shoddy PHP apps, hacks, script repositories and general, unmaintainable spaghetti code?

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).

I never understood the simultaneous hate of PHP and praising of JavaScript.

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).

JavaScript has a mixed praise. Some people hate it but still use it because it's the only option, while other people love it to death.

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.

There's awful, and then there's 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.

I write javascript and php code for a living, and i don't think they're in the same class. Javascript is a nice language with warts tacked on, php however is not a nice language no matter how much you squint.

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).

PHP's popularity comes from the fact that it has good documentation, it's easy to deploy, there are lots of ready-to-use solutions written in it and its core API has many methods to solve common problems.

PHP's documentation is one of the worst I've found. Generally I have to hunt down edge cases and weird behaviors in the comments section.

Google IO 2014: App Engine now supports ColdFusion.

I don't see it :). ColdFusion is both hated and relatively unpopular, PHP has popularity going for it.

PHP is a solid workhorse. Quick to prototype, and once a PHP app is up and running, it just works.

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.

You attribute high availability to the infrastructure entirely, not just a front facing programming language. Facebook has a massive architecture and only it's front-end stuff (views, data retrieval) are done in PHP. Everything else are separate services written in Java (or some other JVM language) and communicate through Thrift. PHP isn't accredited with Facebook's high availability and Facebook doesn't even serve PHP, it serves compile C++ code that was compiled from PHP.

Given Google's reputation of awful customer support, why would anybody want to locked into their platform, especially when you have to do so many things the "app engine" way?

You can run Django on top of AppEngine and port your app to any number of Django hosts with minimal changes. I just talked to a startup founder who started out on AppEngine and just recently switched to Heroku.

Last year I spent a number of months porting an (albiet poorly written) django app from AppEngine to AWS. I would not call the number of changes we made in order to port the app "minimal". I have heard similar stories from other development teams. My evidence is totally anecdotal, but so far it's lead me to believe AppEngine is not a good solution for running a django app.

Did you happen to ask why they decided to move from AppEngine to Heroku?

Didn't offhand - I just saw him in the hallway for 5 minutes or so while he was in town for I/O.

They have introduced upgraded "Support Packages" for a premium: https://cloud.google.com/support/packages

If you have an application that happens to fit nicely into the App Engine Way, it's a pretty slick environment for deployment.

Yes, I have no argument with you that it is quite slick. It seems the benefit still does not outweigh the cost though. I can't even imagine running into a critical issue with paying customers demanding answers from me while I am subjected to Google's customer service. Plus there's no way to failover from App Engine to some other platform if your app is locked into the "App Engine Way".

The only thing I would consider using App Engine for at this point would be a school project or something.

> Plus there's no way to failover from App Engine to some other platform if your app is locked into the "App Engine Way".

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".

[1] http://www.appscale.com/

> Well, except that there is an open-source alternative implementation of App Engine that you can run anywhere you want.

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.

It's an incredibly quick way of getting something out there.

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.

Some parts of app engine are very much designed to be really scalable and geographically redundant. Take sharded counters, for example [1], if you want to count something that happens more than 5 times a second.

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...

I recently left a job that was focused on developing PHP with a very different philosophy from how I would approach it.

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.

It looks like they have preemptively documented how to install Wordpress: https://developers.google.com/appengine/articles/wordpress

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.

AJ here, a PM on App Engine (and the guy who wrote the tutorial). The Batcache plugin (which caches to Memcache) works on GAE out of the box, and gives a predictable improvement to performance, especially when you've got a lot of DB-heavy plugins.

That's a nice tutorial and the idea of running Wordpress on GAE is intriguing to say the least.

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.

Google Cloud storage is a great place for uploaded media (it's pretty efficient at serving), and the PHP runtime integrates quite cleanly into GCS (you can fwrite() to a GCS object, for example).


We're working with a couple of Wordpress developers on a plugin to integrate Wordpress media uploads with Google Cloud Storage.

As Cloud SQL will provide it's own security features


Thanks, will fix :)

PHP??? I would have thought javascript or Ruby would have made more sense.It seems like Google is just reacting to requests from 4 years ago.

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 was the single most requested feature on the bug tracker by quite a bit.

It's not something I want, but apparently there are quite a few people who do.

Our goal is to advance computing (via services such as HRD, Cloud Datastore, BigQuery, and Go) in ways that align with existing developer practices (investments in Java and now the release of PHP). There's no point in releasing amazing solutions if there is a huge barrier to entry.

Which customers are you going after? People who want to play around with "hello worlds" with PHP or people who actually build powerful stuff.

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!

I'm assuming that you're actually talking about Node and not just HTML + JS. Ultimately it wasn't a choice to do one and not the other, it was a choice of which to tackle first (and PHP had some technical advantages which allowed us to move faster). Ultimately we want to surface, or allow others to surface, any runtime in a fully managed way. Yes, Node, Ruby, C# are often discussed (as are many others, including moving Go to GA). We're investing, we'll get there, and this is only the first of many steps.

I don't necessarily mean Node, but serverside javascript. I don't really care for the event notification process of Node. It has its place and for many tasks it probably is the best solution. However for most web apps its probably simpler not to worry about it.

Yes, PHP is only used for amateur useless projects like Facebook, Wikipedia, Drupal, WordPress ... Our projects on the other hand are too important for this low brow language.

All the stuff you are talking about are valid examples, but they are from 5-10 years ago. None of these probably will be built on PHP again. I can use the same reasoning and list some major critical applications and argue for Cobol, Fortan, etc. But it doesn't mean it's forward thinking.

We get requests for PHP all the time. In Urs' presentation today, the audience response at I/O was the strongest for three things specifically - open signups for GCE, sub-hour GCE billing, and GAE support for PHP.

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.

Excellent points.

Is there a MySQL-like solution on GAE as well?

While PHP has low barrier to entry and there are a lot of people who tinker with it, PHP still powers a lot of production websites, far and beyond the hello world apps or the 'pictures of my dog' wordpress blogs. Your implication that there aren't "powerful stuff" websites running on PHP is just simply not true.

You can host HTML, javascript and CSS files to be run in the browser on GAE already, and have been able to do so since day 1.

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.

> 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.

Serverside. Not static client side files.

Is this cumulative requests from the past 5 years?

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.

> Also what people request and what google's vision is are two different things.

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.

"Lots of kids playing around with PHP" "People who want to play around with "hello worlds" with PHP"

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.

Google Drive / apps script integration is a great idea. Unifying our storage offerings across the entire company is a great idea too (but an aside for this conversation). I disagree with the "get something out" mentality, though. Shipping a fully managed runtime that scales as well as Java, Python, and Go, that is hardened, and is secure enough that we'll run it next to Gmail, Search, Geo, etc. is no easy task. It's not something you decide to do on a whim a few weeks before i/o.

I just wouldn't have guessed the people who requested PHP would use much resources—if you're scaling, you probably know better than to use PHP in the first place.

You can do JS and Ruby via a JVM-based runtime (jruby, or whatever for JS). Don't know how much uptake it has. I know I've seen proof of concepts of jruby on app engine, including with Rails.

I know you can but it's not clean. Also with Groovy on Grails early on there was some issues with timeouts if you're applicant wasn't popular, that was until GAE allowed to run a hot instance. Probably why it didn't have an uptake.

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.

I would guess at least an order of magnitude more Enterprise web applications currently in use are written in PHP than Javascript and Ruby combined.

To all the PHP haters. Feel free to bask in the glory of knowing pointers and monads like the back of your hand, and leave making useful apps and making money to PHP developers. That's fine with me :)

Google Compute Engine - now available for everyone *

* 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'.

GCE does not impose any vendor lock-in. It's just VMs on demand, so it would be easy to migrate to Amazon EC2, Rackspace, etc at any point.

100% try 500-1000%

The "they will hike prices 10x when it's popular" meme is pretty tiresome.

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.

It's realistically priced right now, and it's an underdog in the market, positioned as a commodity. Raising prices would kill it stone dead.

And now we know why Guido left to join Dropbox ;-)


I like PHP! It's the first OO programing that I learned and paved the way for me learning C, C#, Obj-C...and now I'm studying Java. If it wasn't for Php's loose declarations (as compared to C) than I would have had a harder time to grasp object oriented programming and would've never made it past javascript.

Why does every PHP thread turn into a bashing session? It's not constructive to the conversation. I for one am excited about this. I'm only half way through the docs buy so far I like what I see compared to other PHP PaaS. Except no mbstring.

Have you tried mb_string?

Does anyone know when Go 1.1 is available on App Engine?

It'll arrive in the next release or two.

I cannot possibly hope to express the reasons I dislike PHP better than this comprehensive article: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

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.

This has been reiterated over and over again and is just a bunch of fluff. It doesn't explain why PHP is bad with examples and while I know there are a ton of sites that do, many people including myself have used PHP successfully in the past.

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.'

Being able to successfully use something doesn't mean it was a good idea.

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.

> It doesn't explain why PHP is bad with examples

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.

The very first example about @fopen is full of weird stuff about INI file changes and stuff that are not on by default and if someone turns them on they should understand what they are doing.

Really? I've heard all these ridiculous analogies but for some reason no one's every written up actual PHP examples to explain why this is true (Most of the examples in that link are weird things I've never seen anyone actually do).

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).

    php > $x = array("a" => 1, "b" => 2);
    php > echo $x["a"] . "\n";
    php > echo array("a" => 1, "b" => 2)["a"] . "\n";
    PHP Parse error:  syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1
I don't mean to denigrate everyone who uses PHP. But there's a whole world of great languages out there, and the vast majority of them act in more consistent (not to mention pleasant) ways than PHP.

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.

Weird things you've never seen anyone actually do? Test for equality, build data structures, handle error conditions?

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.

I'm starting to wonder whether there should be a version of Godwin's Law for Hacker News: As any thread mentioning PHP progresses, the probability of a poster mentioning "A Fractal Of Bad Design" approaches 1.

Got it. You don't like PHP. I don't think that has much to do with this announcement. I don't like Java, but I do not feel offended that GAE supports it.

I probably should have posted that in the existing php-sucks party above, I suppose.

I seriously only added this metaphor as an afterthought, after pulling it out of my ass to explain all the furious typing to my partner. It's pretty funny that it's become the most famous part of the article.

It's definitely the most quotable bit. I'd say you actually make your point a lot better through sheer quantity, but that's a bit harder to convey in excerpt form.

I wonder whether the target audience here is developers who want to build a new PHP application from scratch for GAE, or just people who want to install Wordpress? Using GAE adds a development/deployment step, but the lack of deployment fuss is the primary advantage PHP has over anything else.

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.

PHP as just started to get a package community going (Composer) but it's incredibly slow. Using external packages in PHP isn't as easy as with other platforms.

Surely Google could just preinstall something. The Python templating docs say GAE includes both Jinja2 and the Django template engine.

Learn to write code - languages won't matter then. A spade is a spade whatever it is made of.

I can't seem to find the registration form, how does one get started?

I'm Zafir, I work on the Cloud Platform team. Compute Engine will be available tonight, so please check back in a few hours.

Awesome, thanks!

I just signed up here: https://gaeforphp.appspot.com/

Whoops, I thought the question was about Compute Engine. Yes, you can sign up for PHP on App Engine at the link you provided.

It was about Compute Engine actually. For those who are interested, the GCE page says registration opens at 6PM PST on May 15th, 2013.

You can sign up now!

There goes the neighborhood.

I know there's google people floating around HN, does anyone know what the priorities are like as far as adding more services is concerned? I've been planning on launching on AWS, but I'd prefer google. But there's still tons of services google doesn't offer (or I can't find reference to at least). It is basically just alternatives to EC2, S3 and the database thing right now right? Are there plans for replacements for SQS, SNS, SES, route53, cloudwatch, etc?

It's been years since Google actually released something useful on GAE. All while AWS has blown it away with an array of new systems e.g. SWF, EMR, Glacier, Transcoder.

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.

> It's been years since Google actually released something useful on GAE.

Do try to keep up: https://code.google.com/p/googleappengine/wiki/SdkReleaseNot...

When it comes to my (virtual) infrastructure, I want to go with a platform that's stable (including in terms of price), well-tested by others who have similar needs as me, and has a lot of documentation / articles / questions online. And I would never go with a platform that doesn't have all other services that I may need (as you mentioned). Why wait for google replacing SES when you can just go with AWS? MHO, obviously!

GCE seems like another "me too" product. The PaaS thing didn't work out so well for Google or Microsoft. When they realised AWS was much more popular with IaaS they simply set about copying AWS. They are years behind AWS and by the time they catch up with what AWS has today the world would have moved on to bigger and better features.

So many new "me too" clouds, Azure, Rackspace, HP, even Oracle, and now Google.

Google's offering is significantly faster, and is marginally cheaper is it not? I've had relatively poor experiences with the quality of documentation/articles/questions for AWS, I still haven't managed to get a simple s3 setup working to allow people to upload files through their browser for example. I'm not waiting for google, we're not ready to launch yet. I am just wondering if google will have some of the extra services by the time we are ready.

I'm looking at GAE as a AWS alternative too, so what follows is not complete, just a few observations.

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/

>I think of GAE as more like Heroku + add-ons than a straight AWS competitor

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact