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

Dear Google Cloud: Your Deprecation Policy Is Killing You

medium.com

Post reply on HN
Print view View original

391–400 of 417 posts

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

#391

Post by otterley »

sukilot wrote: post #385
fh973 wrote: post #75

I think Google couldn't do better, even if they wanted to. The reason is the engineering culture and the promotion system. People expect to switch to new projects, and work towards to a promotion within 2-3 years. This shows in all products, and presumalby also the reason for the deprecation. New people come on the project, want and need to do a major overhaul, and do not have resource or incentives to support the ol…

That could be fixed in 1 day if the CEO simply said hire people to maintain this stuff, and don't require them to get promoted. Google's a mega corp now, not a startup. And they pay white well at entry level. Most people don't care about promo unless forced (up or out).

You grossly underestimate how long it takes to change the culture of a company, let alone one the size of Google. A CEO can’t snap his/her fingers and direct a change of this kind into existence.

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

#392

Post by lowiqengineer »

sandeeps_ wrote: post #371
lowiqengineer wrote: post #340

Earlier quoted context omitted.

>You have the opportunity to leverage that and either get promoted from within or change jobs. I think the real problem is I'm not capable of doing so, at least according to the fair labor market. > Are you really struggling making $150K straight out of college? You graduated from a state school (as did I) you probably don’t have that much debt. I don't have any debt, I just have a really pathetic savings rate and a…

>> I don't have any debt, I just have a really pathetic savings rate and a really low net worth compared to nearly everyone I know, including folks that didn't do "the grind" that I did. I'll probably not be able to retire or own a car, much less own a house someday. Dude, please seek mental help. You have so many working years ahead of you. Stop worrying about owning a house. Start budgeting using something like YNA…

> Stop worrying about owning a house

A lot of my friends are already putting money down on houses and are making hundreds of thousands in options trading on principal that I _don't have_. I'm falling behind permanently and even maxing out my 401k (which I didn't do last year because I don't anticipate living to 65 but decided to this year) won't get me closer with a low principal.

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

#393

Post by sharpneli »

Jabbles wrote: post #116
sitkack wrote: post #66

> Let’s say hypothetically that Apple was dumb enough to pull a Guido van Rossum, and declare that Swift 6.0 is backwards-incompatible with Swift 5.0, much in the way that Python 3 is incompatible with Python 2. Damn, I was waiting for this. The whole essay was a setup for this paragraph. Reframes the argument using a shared traumatic experience for everyone. This humanizes the effect, we all know someone that lost s…

Apple already ~mandated moving apps to Swift. I don't see why they couldn't do it again? Purely because of the existence of Flutter?

Good luck on deprecating Objective-C and the C++ toolchain.

As an example core of Unity is written with C++ with Objective-C bindings for APIs such as Metal.

If Apple would mandate Swift then things like Unity would just cross compile into swift, causing perf regressions for users, all for no benefit for Apple.

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

#394

Post by dekhn »

Avamander wrote: post #256
sitkack wrote: post #66

> Let’s say hypothetically that Apple was dumb enough to pull a Guido van Rossum, and declare that Swift 6.0 is backwards-incompatible with Swift 5.0, much in the way that Python 3 is incompatible with Python 2. Damn, I was waiting for this. The whole essay was a setup for this paragraph. Reframes the argument using a shared traumatic experience for everyone. This humanizes the effect, we all know someone that lost s…

I don't get the Python3 bw-incompatibility hate. Getting rid of cruft is literally the only way to get rid of cruft. It's literally the Pythonic to not have cruft. I dread the day Python will be as bloated as C++ or Java, neither that dare to remove things.

Python3's intentions were good, but the execution was abysmal. It was just a bunch of extra work on top of what should have been a pretty straightforward migration.

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

#395

Post by dekhn »

efreak wrote: post #360
toast0 wrote: post #47

Earlier quoted context omitted.

You missed this: > I’ll also give a shout-out to our friends in the Operating Systems business: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, and so on, for doing such a great job of backwards compatibility on their successful platforms. I share your desire for stability. I don't necessarily mind frequent updates for security reasons, but I'm getting to the point where if things are changing in big ways often, I…

Linux code might be backwards compatible, but nothing like windows. I can run pbrush.exe taken from Windows 95 on windows 10, and it works fine. Want to run a 10yo binary on Linux? It's easier to set up a VM with a 10yo Linux release on it. You've hot the source code and you can compile it? Well, tough, the build tools have changed, and some autoconf script has been removed, even from autoconf-archive.

Actually, I've kept an ancient statically compiled Mathematica (linux) binary from 2000 and it actually still runs. I had to make some symlinks since X11 font paths have changed. That's a full GUI app with a sophisticated internal kernel.

This should be generally true of any well-compiled static binary on linux from 20 years ago.

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

#396

Post by jen20 »

fauigerzigerk wrote: post #303
plorkyeran wrote: post #294

Earlier quoted context omitted.

Async/await currently looks like it'll be a non-breaking change. Obviously you'll have to redesign a whole bunch of code to actually take advantage of it, but you won't have to adopt it just to upgrade to the newest version of Swift. If you decide it's not worth the effort, you'll have the option to just not redesign anything.

Yes, hopefully not a breaking change, but a lot of APIs and libraries will have to be redesigned completely in order to allow people to take advantage of it. And a lot of old code will look inconsistent for quite a long while. I'm a bit surprised that language support for such a key concurrency feature comes so late in the game. It's not the same issue that Yegge describes though.

“So late in the game” is relative, no? Java doesn’t have it, Rust stabilised it last year after ~9 years (or around the same time period if we’re comparing 1.0 releases).

Async/await does not need to be a breaking change - C# managed fine without it being so. The breaking changes in Rust were around the standardisation of std::futures::Future rather than async and await.

That said async/await makes a world of difference to the usability of Rust for async code and I’d imagine it will for Swift too.

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

#397

Post by jen20 »

School-Cotton wrote: post #354
sitkack wrote: post #66

> Let’s say hypothetically that Apple was dumb enough to pull a Guido van Rossum, and declare that Swift 6.0 is backwards-incompatible with Swift 5.0, much in the way that Python 3 is incompatible with Python 2. Damn, I was waiting for this. The whole essay was a setup for this paragraph. Reframes the argument using a shared traumatic experience for everyone. This humanizes the effect, we all know someone that lost s…

Apple is AFAICT the least concerned of all the major platform vendors about backwards compatibility. Programs routinely stop working on new releases of macOS or iOS, sometimes in ways that are impossible to fix. On Mac they’ve already changed processor architectures twice and look poised to do so again. That’s much more disruptive than the python 2 to 3 migration.

> That’s much more disruptive than the python 2 to 3 migration.

Yet Python 2 to 3 started in 2008 - 12 years ago, and is still not “done” in any meaningful sense.

If I think back to 12 years after the intel OSX transition - 2018 - I can’t think of a single outstanding issue, whereas I bash into python 2 vs 3 literally every time I touch it (and therefore mostly choose not to).

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

#398

Post by steveklabnik »

jen20 wrote: post #396
fauigerzigerk wrote: post #303

Earlier quoted context omitted.

Yes, hopefully not a breaking change, but a lot of APIs and libraries will have to be redesigned completely in order to allow people to take advantage of it. And a lot of old code will look inconsistent for quite a long while. I'm a bit surprised that language support for such a key concurrency feature comes so late in the game. It's not the same issue that Yegge describes though.

“So late in the game” is relative, no? Java doesn’t have it, Rust stabilised it last year after ~9 years (or around the same time period if we’re comparing 1.0 releases). Async/await does not need to be a breaking change - C# managed fine without it being so. The breaking changes in Rust were around the standardisation of std::futures::Future rather than async and await. That said async/await makes a world of differe…

The only breaking change was that async because a keyword, the Futures stuff didn’t cause any breaking changes. There were three major versions of the library before it moved into the stdlib, though.

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

#399

Post by jen20 »

steveklabnik wrote: post #398
jen20 wrote: post #396

Earlier quoted context omitted.

“So late in the game” is relative, no? Java doesn’t have it, Rust stabilised it last year after ~9 years (or around the same time period if we’re comparing 1.0 releases). Async/await does not need to be a breaking change - C# managed fine without it being so. The breaking changes in Rust were around the standardisation of std::futures::Future rather than async and await. That said async/await makes a world of differe…

The only breaking change was that async because a keyword, the Futures stuff didn’t cause any breaking changes. There were three major versions of the library before it moved into the stdlib, though.

Right, by “breaking changes” I mean across the ecosystem rather than in the Stdlib. There’s still a decent amount of code based on futures 0.1 and many libraries that depended on it required rework as a result.
Post reply on HN