Hacker News Reader

Comment by Groxx | Hacker News Reader

tbh the vibe I get is that Google seems to be great at building tools that teach people nothing about how to collaborate with anything outside their current company... so they're both hamstrung when they leave, and then they continue to build new tools that don't work together with anything else because they don't understand the community at all.

Bazel is a perfect example. Bazel projects are horrifically (arguably impossibly) hard to use to collaborate with other Bazel projects outside of your control, and its abilities encourage you to do (useful!) things that don't hold up outside its little isolated world. It's a super great system in a lot of ways, but it is anathema to open source development.

At times it feels like it's probably extremely destructive in aggregate, particularly as more and more companies blindly mimic it, and that worries me.

View on HN

I think that's quite an uncharitable interpretation of what's happening - Google doesn't really have bad intentions here imho, but with every tool you suffer from a conflict of goals: Should it be as good as possible for the current environment or should it work "well enough" in as many environments as possible?

That's also the conflict between external libs/frameworks vs. NIH. Yeah, sure. Sometimes NIH is a matter of arrogance, but it's also a fact that something you build yourself can work far better in your environment and with your constraints than something you took in and then banged on until you have a reasonable fit.

The corollary is of course that open-sourcing such a thing is often rather useless at first, especially if the company that does it (and Google imho is one of the worst offenders here) doesn't really put in the work to make it useful for a wider audience. Which is partially a function of the companies' devs being more used to working with very fitting tools. With those tools which are useful enough you often see a period of adjustment then. A few releases which don't bring much in the direction of new features, but "only" things you need to make it work in more environments.

To your last sentence: I think that in general it's a bad idea to blindly use or emulate what some (especially big) company did. Just because it works well in their use cases, doesn't mean it will work well for others. It's cargo cult programming, which is unfortunately rather popular in our hype driven industry ("New fancy library by x, we have to use this too or we will be done for in six month!")

> I think that's quite an uncharitable interpretation of what's happening - Google doesn't really have bad intentions here imho...

OP didn't talk at all about intentions. OP talked about results.

> ...but with every tool you suffer from a conflict of goals:

Sure. But it seems to me that OP notices that Google's really, really bad at choosing the "Make it so that people who aren't working in a megacorp who can afford teams of dedicated tool wranglers can easily use the tool and interoperate with others who use the tool." option when presented with it.

And like, why would they ever choose that? They have zero need to, because they are a megacorp who can (and do) hire teams of dedicated tool wranglers.

What do you think about Bazel makes it hard to collaborate with other projects (any more than other build systems)?

I mean, very few people use Bazel so you're likely to have to implement Bazel support for any projects you use, but that's no different to other build systems (e.g. until it became a de facto standard I frequently had to implement CMake support for third party C++ libraries I used).

Some of the in-house stuff was built before alternatives were available or scalable, and now there'd be a high cost and friction to trying to change it. Happens in many big companies that have been around for a few decades, it's not because of bad intentions.

Reply on news.ycombinator.com