Live data from Hacker News

Dear Google Cloud: Your Deprecation Policy Is Killing You

medium.com

151–160 of 417 posts

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#151
Ten years ago it would've been inconceivable to me, but I have to admit that my default assumption is that Google cannot follow through on any of its projects. It is no longer a "live player"[1] and lumbers along purely on its draining intellectual endowment and incumbency.

Network effects and increasing anti-competitive practices will keep Google at the top for years to come, but without a cultural reinvention it cannot possibly regain the prestige it once held as an institution.

[1] https://medium.com/@samo.burja/live-versus-dead-players-2b24...

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#152

I do hope the intermediate solution he mentions, tooling that upgrades your code for you, starts to be used more. Go did this in the early days before 1.0, but it is fairly rare still outside the internal Google tools. It is a big chunk of work obviously but it saves a huge amount of downstream work, and lets everyone move forward.

Right? This is a strategy/trade-off that depends on migration tooling that exists and is user friendly.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#153

It's odd to see an article emphasising backwards compatibility, but not a single mention of Microsoft (I even ctrl+F'd the page source to check!) They've regressed a bit in the recent years but I'd still consider MS the gold standard for back-compat. I have Win32 binaries I last modified over 15 years ago, small (or perhaps tiny - size measured in KBs) utilities that I use daily. They worked perfectly on Win95, and s…

The absolute worst in my small experience with it is anything touching the node ecosystem. Try to follow any guide or use any library not updated in the last week and there will be breaking API changes and deprecation warnings everywhere.

This is only a problem in some parts of the ecosystem - but they are the parts that most 'tutorials' are written about, because they look shiny and fancy. If I'm blunt, they're the parts of the ecosystem that HN loves to gloat about in their "how I saved my company thousands of dollars by building a todo app with GlamorousLibraryJS" type posts.

The short answer: if you avoid the shiny tools that claim to do everything, you will not have this problem. And as a special case, avoid Gulp, which is mismanaged.

The single-responsibility libraries that have a well-defined scope, on the other hand, have often been sitting on npm unchanged for 5-6 years, because they are simply done, and they do what they need to. They will very likely never deprecate anything, as there is simply nothing to change.

I would argue that these libraries are actually doing a better job of stability than their counterparts in other languages.

Edit: An additional factor is that it's easy to write a tutorial about an extensive framework with a large scope; there's plenty of stuff to write about. Writing a tutorial about "this is how you make a function call to this library to parse a geo URI", on the other hand, probably isn't going to happen.

So if you follow third-party tutorials, you are naturally going to end up at the packages that are most prone to deprecations.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#154

Earlier quoted context omitted.

I think the culture of Node comes from the earlier culture of in-browser JavaScript. When running on the browser platform you have to make sure your libraries are up to date and maintained, otherwise you're at the mercy of browser updates breaking things from under your feet (this is less bad now, but it was awful in the days of IE Consequently, JavaScript developers got used to the burden of maintenance and rapidly…

I strongly feel that you must have end to end tests while using node because of the dependency hell. Not even knowing if a upgrade of a dependency breaks your system is just hard. Also testing it by hand is just not maintainable.

> Not even knowing if a upgrade of a dependency breaks your system is just hard.

This is true for any language/platform.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#155
post #94

Earlier quoted context omitted.

The absolute worst in my small experience with it is anything touching the node ecosystem. Try to follow any guide or use any library not updated in the last week and there will be breaking API changes and deprecation warnings everywhere.

The sad part about the js ecosystem is that even the biggest corps like Google can't keep their own js ecosystem stable on the last version. I have a small Angular app with Firebase backend and every time I come back to it to update, the libs are out of sync

Google is notoriously bad at maintaining (or even designing) their open-source stuff. I wouldn't say "even the biggest corps like Google" -- Google does considerably worse at this than many hobbyist maintainers! I just don't use Google libraries anymore, if I can at all avoid it.

See also my other comment[1] - Angular is an example of such a magical does-everything framework.

[1] https://news.ycombinator.com/item?id=24168279

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#156

So much ranting, yet not a single example of a GCP product that Google has actually killed. Got examples? I mean, there's stuff like Python 2 support being sunset on managed services, but as Yegge himself points out that's on Guido, not GCP.

The old Firebase API. No longer possible to create new databases that can be used from the old API.

Which in practice meant that "migrating to a new database under a different account" translated into "rewriting half a codebase due to a cascade of breaking changes in the surrounding tooling".

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#157

Earlier quoted context omitted.

I strongly feel that you must have end to end tests while using node because of the dependency hell. Not even knowing if a upgrade of a dependency breaks your system is just hard. Also testing it by hand is just not maintainable.

> Not even knowing if a upgrade of a dependency breaks your system is just hard. This is true for any language/platform.

Strong typing does partially help in this situation though.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#158

Has AWS ever sunsetted a service? I know they deprecated SimpleDB but I don't think they ever actually shut it down for existing customers, that might have changed in the last few years though.

As you mention my understanding is that that there’s one service no longer offered to new customers but they are still supporting it for those that were using it. This is a big difference between AWS and Google’s approach to customers. A number of friends’ companies got hit really hard when Google suddenly decided they no longer wanted to do something anymore (regardless of what their customer thought). That list is big and growing: killedbygoogle.com

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#159
post #94

Earlier quoted context omitted.

The sad part about the js ecosystem is that even the biggest corps like Google can't keep their own js ecosystem stable on the last version. I have a small Angular app with Firebase backend and every time I come back to it to update, the libs are out of sync

Google is notoriously bad at maintaining (or even designing) their open-source stuff. I wouldn't say "even the biggest corps like Google" -- Google does considerably worse at this than many hobbyist maintainers! I just don't use Google libraries anymore, if I can at all avoid it. See also my other comment[1] - Angular is an example of such a magical does-everything framework. [1] https://news.ycombinator.com/item?id=…

Tensorflow is another example of this.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#160
Can't help wondering if some of the fall-off in Rails usage is due to a similar attitude toward deprecation of formerly supported APIs, which has made upgrading large Rails apps to a new major release a pretty significant project.

Things they've removed have included the entire original ActiveRecord query API, and the RJS templating system for Javascript. Those two required rewrites of significant portions of any app that tried to bridge the transition using only supported APIs. And every new point release (say, 5.1 to 5.2) brings a enough more minor deprecations to make an upgrade not a task, but a project. That's forcing a lot of significant rework, and every one of those gives people a chance to just take their project elsewhere.

(There's actually a third alternative. The release after these two major components were removed from core Rails, they were still semi-supported as add-on libraries. In both cases, core support for those was ultimately cut off -- but people with old apps could try to keep at least portions of them working to minimize the damage. I've done that to help avoid rewrites in components of an older Rails app. I didn't support all of either old API -- for example, rewriting uses of deprecated options to `belongs_to` was easier than keeping them on life support. But on balance, it was easier than the rewrites.)

Post reply on HN