Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why should anyone ever use a Google API again?

googlecode.blogspot.com

Post reply on HN
Print view View original

121–130 of 185 posts

Re: Why should anyone ever use a Google API again?

#121

Post by billswift »

tybris wrote: post #101
jmathai wrote: post #2

I can't state this enough. Building your company which heavily relies on an API provided by someone else is risky business. Why are we still in this infatuation stage of ignoring the pitfalls of this?

There are billion dollar companies like NetFlix completely reliant on AWS APIs.

I would be willing to bet that most of them have mitigation strategies in place that they can, at least in part, switch to. They don't use them because they are less cost effective than AWS (or other current providers) but they should be able to switch with relatively little notice.

Re: Why should anyone ever use a Google API again?

#122

Post by saurik »

georgemcbay wrote: post #120
borism wrote: post #115

Earlier quoted context omitted.

have you tried migrating to Python 3.0 yet?

Irrelevant to the grandparent's point because your Python 2.x interpreter isn't going to stop working at the whim of an outside party.

This argument come up often, but makes no sense as it ignores the fact that software rots. I cannot keep running Python 2.x indefinitely without maintenance because knowledge of its flaws will slowly escalate until it is a security risk to keep operating it. If this doesn't happen to the tool itself, then it will happen to one of its critical dependencies, like an old version of SQLite it requires, or the previous generation of OpenSSL.

Projects like Python, that simply don't care about maintenance costs of things that rely on it are simply being naive: they are pretty much saying "yes, you invested a ton of time into building code for Python 2; but those days are over: we, at some random shifting date in the future, are going to drop support for this, so if you want to get security updates to it, or hell: even upgrade to a newer version of Ubuntu with minimal pain, you now need to drop everything you are doing and reread all of that code to update it for our seemingly arbitrary changes, retesting the whole thing in the hope of finding any regressions you introduce; that, or go off-grid, maintaining this code and related infrastructure yourself". Seriously?

Imagine if Linux 2.6.100 decided to drop support for socket(), because it is (truly) a painful API to support multiple transport layers with; /even if/ they said "dude, you can still just type socket_old, and we have a crazy preprocessor that hopefuly, if your code is obvious enough, does this search and replace for you", would you still be able to take their dedication to being a platform seriously?

Re: Why should anyone ever use a Google API again?

#123

Post by jmathai »

fjabre wrote: post #94
wccrawford wrote: post #7

You mean, why should you build a for-profit product while relying on someone else's not-for-profit API? I'm guessing you shouldn't! I've seen a lot of neat projects come from Google APIs, but that's as far as I'd taking it. Relying on someone else's good will for the lifeblood of your company is insane. 1 exception, though: Getting started. I could see using Google to get off the ground and then switching to a more r…

Relying on someone else's good will for the lifeblood of your company is insane Tweetdeck anyone? And Zynga (FB is its lifeblood) Google shutting down an API that thousands of developers are relying on without much warning is insane. The web is an increasingly competitive space and there are lots of walled gardens to worry about. Google openly encourages developers to build on top of and use its APIs and it prides it…

>> Tweetdeck anyone? And Zynga (FB is its lifeblood)

Exceptions are not the rule.

Re: Why should anyone ever use a Google API again?

#124

Post by tonfa »

alanh wrote: post #58
SriniK wrote: post #29

Earlier quoted context omitted.

Google is doing the right thing that would be typical for an internet company. For any product they would need to have maintainers/owners who are continuously updating and monitoring. It is completely waste of time to maintain unused stuff.

You are making a false assumption. I personally use the FeedBurner API to keep track of feed subscribers, for example, and it was deprecated yesterday.

Yes, and it is deprecated, not shutdown: "we have no current plans to remove existing functionality".

Re: Why should anyone ever use a Google API again?

#125

Post by alanh »

tonfa wrote: post #124
alanh wrote: post #58

Earlier quoted context omitted.

You are making a false assumption. I personally use the FeedBurner API to keep track of feed subscribers, for example, and it was deprecated yesterday.

Yes, and it is deprecated, not shutdown: "we have no current plans to remove existing functionality".

Fair point, but isn’t that basically what deprecation is? A communication that something will likely stop working at some point?

Re: Why should anyone ever use a Google API again?

#126

Post by nikcub »

naa42 wrote: post #119
nikcub wrote: post #112

Earlier quoted context omitted.

yes but you can take an app from the 80s and still run it on Windows 7 today

With DOS emulator. There is no problem to run DOS app from 80s on Linux/MacOS/whatever with dosbox. By the way, dosbox is far better for some apps than DOS emulator from Windows XP/Vista/7.

you are not understanding the issue here. we are talking about the windows API - they have supported every aspect of it in a backwards compatible way since its inception.

read the Raymond Chen blog about how they used SimCity as a benchmark to test if their backwards compat was working. Marc Andreessen is even on the record as being an admirer of the Windows backwards compat work. they put a lot of work into it and placed a high value on it because they did not want to break developer trust.

Re: Why should anyone ever use a Google API again?

#127

Post by njharman »

bad_user wrote: post #46
wccrawford wrote: post #7

You mean, why should you build a for-profit product while relying on someone else's not-for-profit API? I'm guessing you shouldn't! I've seen a lot of neat projects come from Google APIs, but that's as far as I'd taking it. Relying on someone else's good will for the lifeblood of your company is insane. 1 exception, though: Getting started. I could see using Google to get off the ground and then switching to a more r…

Google's App Engine is pretty much a for-profit API. And now they've announced a change in their pricing scheme, which if true, would change App Engine from pay-what-you-use to same-as-amazon-aws-but-pricier scheme, which makes it hugely expensive for a large portion of devs that have built on top of App Engine. And migrating away from App Engine is a total pain in the ass. I truly hope that the blog-post missed impo…

> expecting instability in the implementation, not in its pricing scheme. I mean, come on!

Really, really? Come on, these very same concerns (pricing, it's beta) were/are brought up regularly. If you choose to ignore warnings/recommendations and use GAE that's your fault.

Re: Why should anyone ever use a Google API again?

#128

Post by akkartik »

fjabre wrote: post #94
wccrawford wrote: post #7

You mean, why should you build a for-profit product while relying on someone else's not-for-profit API? I'm guessing you shouldn't! I've seen a lot of neat projects come from Google APIs, but that's as far as I'd taking it. Relying on someone else's good will for the lifeblood of your company is insane. 1 exception, though: Getting started. I could see using Google to get off the ground and then switching to a more r…

Relying on someone else's good will for the lifeblood of your company is insane Tweetdeck anyone? And Zynga (FB is its lifeblood) Google shutting down an API that thousands of developers are relying on without much warning is insane. The web is an increasingly competitive space and there are lots of walled gardens to worry about. Google openly encourages developers to build on top of and use its APIs and it prides it…

Google shutting down an API that thousands of developers are relying on without much warning is insane.

What constitutes 'much warning'? Translate API users have six months. Were you thinking of a different API?

People using the APIs knew the policies for deprecation in the ToS, I presume?

Re: Why should anyone ever use a Google API again?

#129

Post by glenjamin »

saurik wrote: post #122
georgemcbay wrote: post #120

Earlier quoted context omitted.

Irrelevant to the grandparent's point because your Python 2.x interpreter isn't going to stop working at the whim of an outside party.

This argument come up often, but makes no sense as it ignores the fact that software rots. I cannot keep running Python 2.x indefinitely without maintenance because knowledge of its flaws will slowly escalate until it is a security risk to keep operating it. If this doesn't happen to the tool itself, then it will happen to one of its critical dependencies, like an old version of SQLite it requires, or the previous ge…

There's a big difference between flicking a switch to turn off python 2, and slowly deprecating it over a period of years to a new (better) system with well doucmented differences and a clear migration path.

Python 3 started in 2006 (http://www.python.org/dev/peps/pep-3000/), if you've managed to stave off software rot for the last 5 years, I'm sure you can take the extra step to support python 3.

Re: Why should anyone ever use a Google API again?

#130

Post by saurik »

glenjamin wrote: post #129
saurik wrote: post #122

Earlier quoted context omitted.

This argument come up often, but makes no sense as it ignores the fact that software rots. I cannot keep running Python 2.x indefinitely without maintenance because knowledge of its flaws will slowly escalate until it is a security risk to keep operating it. If this doesn't happen to the tool itself, then it will happen to one of its critical dependencies, like an old version of SQLite it requires, or the previous ge…

There's a big difference between flicking a switch to turn off python 2, and slowly deprecating it over a period of years to a new (better) system with well doucmented differences and a clear migration path. Python 3 started in 2006 ( http://www.python.org/dev/peps/pep-3000/ ), if you've managed to stave off software rot for the last 5 years, I'm sure you can take the extra step to support python 3.

Upgrading to Python 3 is simply not an option for me at this time as I am depending on libraries that still require me to be using Python 2: Python 2->3 is an "all or nothing" endeavor due to the horrendously incompatible way they have handled this transition. I mean: the fact that five years /have/ passed and Python 3 is still a silly pipe dream for almost all users of Python should tell you something about how poorly this was done.

Now, of course, to the extent to which I can, I've used Python 2.7's "from __future__ import" mechanism to pull as many features as I can from Python 3 to help transition, but even that has been stupidly painful: importing Python 3's gratuitously different division operator (which you can't automatically process and convert as you need to know whether the denominator is a float or an integer) was very very VERY painful on all of my careful image processing code (suddenly getting, or not getting, half pixel offsets and widths in various places).

Meanwhile, I don't see any benefit at all to me making these changes... requiring "as" instead of a comma for exceptions?... /removing/ the 2.7 ability to mark a string constant with a b-prefix, forcing an ambiguity between 2.6 str and 3.0 bytes? Are you seriously telling me that these were so important as to cause there to be a five year rift in the language community?

In all seriousness, a better usage of my time (rather than messing around porting my 2.x code to 3.x code) would have been to make a patch to Python 3.x to let you "from __future__ import hindsight" to let you use Python 2.x syntax with the Python 3.x interpreter, at which point 99% of these incompatibilities would be irrelevant. Of course, hindsight /is/ 20/20: I can't go back in time and reinvest that time better; but, I certainly have learned my lesson about using Python.

Post reply on HN