4 ms·
To me, the strongest motivation for Bazel arrives with a complex (slow) build spanning multiple technology ecosystems. Bazel does a great job building all of th
by kylecordes 6y ago
To me, the strongest motivation for Bazel arrives with a complex (slow) build spanning multiple technology ecosystems. Bazel does a great job building all of them, without privileging one over all the others. It has all the key features you'd expect, dependency graph control, caching, distributed computation, etc. You can add support for whatever local complexities invariably arise with custom rules.
The Java ecosystem has much of that available also though - even a large Java-only project is somewhat tough to justify moving away from the tools almost every developer will arrive already knowing.
- erik_seaberg 6y agoIt came from Googlers, who are kind of notorious for not using the rest of the industry’s tools. Sometimes it’s because they pioneered the problem space, and their own tools really are that much better. Sometimes their tools used to be better but are now just tech debt. Sometimes it’s promo-driven development.
- vips7L 6y ago> Sometimes their tools used to be better but are now just tech debt This is how I feel about most of Googles Java libs (guice, guava, gson). They used to be better, but now they're just tech debt.
- alexhutcheson 6y agoWhat are the best-in-class replacements for those?
- vips7L 6y agoGuava -> The JDK Std library, unless you need more performant collections provided by it. Guice -> If you need to support the jakarta.* namespace the only real answer is Weld or another CDI compliant implementation. Otherwise guice is probably still fine. GSON -> Jackson as always.