Hacker News new | ask | show | jobs
by Strom 2486 days ago
> And Google is giving exactly the guarantees they promised - 1 year of notice before shutting down a product.

This is mostly true, but a bit more nuanced than one might think. Let's take the Go 1.9 runtime for App Engine. It was deprecated on June 27, 2019. [1] Existing deployments will keep working for an undetermined time, however new deployments won't be accepted starting October 1, 2019. That's just a 3 month notice! The offered solution is to migrate to Go 1.11 [2], however that's not straightforward either, because the Go 1.11 runtime is using 2nd generation App Engine, which means a bunch of App Engine specific code that you had working before will need to be rewritten. To make things even more spicy there's already a migration path to Go 1.12 which deprecates every single App Engine specific API. [3] Google is basically slowly shutting down the whole 1st generation App Engine.

--

[1] https://cloud.google.com/appengine/docs/standard/go/release-...

[2] https://cloud.google.com/appengine/docs/standard/go111/go-di...

[3] https://cloud.google.com/appengine/docs/standard/go112/go-di...

1 comments

Note: I work on App Engine. Go 1.11 supports all legacy 1st generation APIs. It's in the first section of the doc [2] that you posted although perhaps we can make this even clearer. We maintained support for these APIs precisely to make this migration extremely straightforward for our existing users as we moved to a more modern underlying technology stack and a version of Go supported by the language community. We absolutely want App Engine to be a place you can confidently build a business upon.
Was this done proactively or reactively after many months of negative feedback? If it was the former that gives me a lot more faith in app engine after trialing in some years ago and giving up on it.
Proactively. It was in the initial email about the Go 1.9 turndown sent to users. We definitely understand that any code change is painful, no matter how trivial. Supporting legacy APIs on a modern Go runtime seemed like the right balance between keeping up with the language community while bringing along our existing users.