Live data from Hacker News

Bazel 1.0

opensource.googleblog.com

51–60 of 204 posts

Re: Bazel 1.0

#51
For me, the difference between other build systems and bazel was like the shift from CVS to git... Profoundly better internal data model, but definitely a learning curve.

Re: Bazel 1.0

#52
post #3

Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?

My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…

Dude, IDK if you have used bazel OUTSIDE of Google, but I've used it both inside and outside of Google and I can tell with 99.999% confidence that the experiences are dramatically different.

Bazel != Blaze (internal version of Bazel).

1. Google has a well maintained monorepo. Most companies don't. That diminishes the meaning of a good build system in the very first place; even if Bazel is powerful, with separate repos it's power isn't the shiniest.

2. Google open sources a part of Blaze, which is the external Bazel, but not all to it. That's what Google does with basically everything it open-sources. The outcome then, is that the external tool require you to build a lot of other not open-sourced tools to replicate the excellence of the entire Google internal eco-system that makes the internal tool so amazing. Same goes with Bazel. It works amazingly internally because there are so many people supporting it, and so many other tools work nicely with it. But not all the features and tools are open-sourced together with Bazel, so the diff of experiences internally VS externally is significant.

TL, DR: if you're a small company without a good monorepo strategy and someone experienced on this, DON'T EXPECT BAZEL TO BE YOUR MAGIC CURE.

Disclaimer: my current company uses Bazel pre-1.0 and it's definitely dramatically worse than what I used internally at Google. I haven't tried 1.0 but I don't expect the ecosystem problem to be solved in 1.0 anyways. Also Bazel sort of sucks for python anyways. Really hoping someone can prove me wrong and say 1.0 is actually the lit shit.

Re: Bazel 1.0

#53
My only experience with Bazel is using it for Tensorflow (TF). It seemed very roundabout for what was required and definitely had some painful version issues as TF got closer to 2.0. Hopefully this means more stability and ease of use going forward for TF users.

Re: Bazel 1.0

#54
post #6

Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.

I’m getting a little tired of this particular brand of lazy cynicism. I’m happy to see people inventing new build systems, programming languages, game engines, ORMs, or anything else where the conventional wisdom is to use the existing tools. It may be crazy optimistic but we need people to keep these skill sets alive.

Bazel is hardly new, it’s been in use at Google for many many years as Blaze.

Re: Bazel 1.0

#55

I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.

There are native code compilers for Java, one just has to bother to learn about them.

Plus, even if one does not use them, shipping a minimal runtime is hardly any different from having libc or libc++ dynamically linked.

Re: Bazel 1.0

#56
post #3

Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?

My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…

How you have an ads taskbar Java app.

Doing Java since it was introduced in 1996 and never got to see Java ads on the taskbar, must be a special version.

Re: Bazel 1.0

#58

Earlier quoted context omitted.

My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…

On Linux I just install a headless OpenJDK 1.8. Something similar is available through brew on the Mac. Oracle’s version is dead as far as I care.

Who do you think writes 90% of OpenJDK and drives language design?

Re: Bazel 1.0

#59
In my opinion Bazel/Blaze and Buck are mainly useful to solve the problem of having too much code to build on one machine. Reproducible builds which can be done in a distributed fashion aren’t really useful when you can build your whole project in a minute or two on one machine. That being said, once you get the hang of it the overhead is not too high compared to simpler systems.

Re: Bazel 1.0

#60
post #34

Earlier quoted context omitted.

Why do you care if a JVM is on your dev machine?

My 2015 MBP is crawling between Safari, Docker, VS Code, and BitDefender (antivirus). Not sure how bulky the JVM is these days. That said, I wish it supported Python.

Why do you even have Bitdefender installed?
Post reply on HN