Hacker News Reader

Comment by BoorishBears | Hacker News Reader

I know Google Poly since I'm in game dev (but as a hobby these days, so all the art has to come from my non-3d-artist self or places like Google Poly)

The fact that they won't just freeze uploads and leave it up is just stupid.

People always bring up "What about maintenance costs in terms of dev time!", but at the core this is literally static assets. No fancy API, no crazy isomorphic app or something needing fat servers.

Just 3D modeling files.

Literally they could generate a static page for each asset that uses the preview image instead of the 3d viewer, stick it in their cloud storage solution, and have it exist, untouched, in perpetuity.

The cost wouldn't even register on a microscopic scale for a place like Google

View on HN

Complete second hand / third hand heresay but:

The reason google kills everything is because they do everything via monorepo. So if they don't have enough devs to literally -keep a service up to date with the currently evolving stack- they have to kill the project. This is why things get killed so easily.

Makes sense to me from a "why canyt you just leave it on" standpoint. But it still makes me very leeery of trusting any project of theirs long term (besides search/gmail).

This. Spent almost 3 years at Google and my view is that it is an intended side benefit of how they do development.

If something that relies on say, one of their log services, and that log service is getting end-of-lifed then all the dependent services that aren't really critical will also get shutdown. It's a forcing mechanism to keep the amount of cruft down. If that service that relies on the old service is that important they'll put the resources on the project long enough to port it to the new service.

This makes sense for engineers but is detrimental from a user point of view. Google effectively taking what would be a few days of engineering time to update some API calls and instead amplifying it and passing it on to users.

When considering whether to learn/migrate to a Google service, everyone should consider this ratio at which Google values your time vs. that of their engineers.

That's the distinction I made above, this isn't like a traditional "app" where the core of it's functionality is dynamic

It doesn't need to stay up to date with an evolving stack

Static files in Google's equivalent of an S3 bucket with public downloads enabled, that's it.

By design these types of blob storage services "just work" as a consumer indefinitely (otherwise there wouldn't be much of a point to them)

I get the whole "who does it get billed to, who's going to take a day to write this script that makes the preview page" deal, but like, this is literally the one time where just a little bit of initiative can win some brownie points with minimal investment, can't they do it?

Reply on news.ycombinator.com