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

Bazel 1.0

opensource.googleblog.com

Post reply on HN
Print view View original

81–90 of 204 posts

Re: Bazel 1.0

#81

Post by blub »

arianvanp wrote: post #79
RcouF1uZ4gsC wrote: post #8

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.

We didn't have Bazel on ARM for NixOS because we can't bootstrap openJDK on ARM. There's no source code for a JVM that compiles on ARM afaik. Though in theory we could package binary blobs from oracle and bootstrap JDK and Bazel from there, it means now our trust path for your critical build tool has a random Oracle blob in its trust path there that is extremely hard to get rid off. Build systems should be easy to bu…

Google builds stuff for themselves and then dumps it for extra reputation points on the dev community.

The part where this starts to suck is when their tools become pseudo-standards and everyone has to live with their decisions.

Re: Bazel 1.0

#82

Post by sz4kerto »

RcouF1uZ4gsC wrote: post #46
paulddraper wrote: post #35

Earlier quoted context omitted.

Bazel doesn't start a server for Java JIT reasons. It starts a server for (1) concurrency control (2) management of worker processes some languages use (3) caching the build graph (recall that Bazel works with very large code bases). These reasons are independent of implementation in C++, Go, Rust, Java AOT, etc. (And yes it doesn't have to use a persistent process to solve these problems. That is the solution it cho…

> (And yes it doesn't have to use a persistent process to solve these problems. That is the solution it chooses.) How much did the fact that Java is very slow starting up influence the decision to use a persistent process instead of some other solution?

JVM startup is sub-second. Still not great for e.g. small command line utilities, but completely fine otherwise.

Re: Bazel 1.0

#83

Post by zmmmmm »

RcouF1uZ4gsC wrote: post #8

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.

I always have the opposite reaction. When I see its a native tool I immediately think, "oh great, now to build this I need to know how to understand your weird glib / gcc version weird compile / link / error for some ecosystem I don't understand". Instead when I see Java / JVM and know that almost certainly I will have no problems like that.

Re: Bazel 1.0

#84

Post by pgrulich »

arianvanp wrote: post #79
RcouF1uZ4gsC wrote: post #8

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.

We didn't have Bazel on ARM for NixOS because we can't bootstrap openJDK on ARM. There's no source code for a JVM that compiles on ARM afaik. Though in theory we could package binary blobs from oracle and bootstrap JDK and Bazel from there, it means now our trust path for your critical build tool has a random Oracle blob in its trust path there that is extremely hard to get rid off. Build systems should be easy to bu…

Is not the openjdk available for arm? What do you need from Oracle? https://adoptopenjdk.net/releases.html#aarch64_linux

Re: Bazel 1.0

#85

Post by taeric »

klodolph wrote: post #39
taeric wrote: post #24

Earlier quoted context omitted.

I agree at a personal level. If anyone is pushing a toy project, basically no reason to knock it. Reason that Serenity OS story a few days ago was awesome. However, solutions pushed by corporations with grandiose claims do strike a nerve with me. If only because they are typically pushed with the idea that they will spread through some technical superiority. I'm much more open to this getting more use strictly from w…

It is successful enough that it has spawned a few clones—Buck, Pants, Please.build, and the thing that Chromium uses now. From what I can tell, before Bazel was open-source, everyone who left Google wanted to use Blaze badly enough to write their own version.

Not exactly ringing endorsements here.

In large, most of the clones you are talking about are because this is a google pushed product. Chromium specifically is because google pushed it in.

Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. It is not uncommon for college or earlier users to just use whatever their IDE does for them. Such that, yes, any automation is welcome after that.

None of this is to say it isn't worthwhile. Heck, they have enough manpower on it that it should be a good solution. It still hits a sour note with me, though.

Re: Bazel 1.0

#86

Post by taeric »

halflings wrote: post #27
taeric wrote: post #24

Earlier quoted context omitted.

I agree at a personal level. If anyone is pushing a toy project, basically no reason to knock it. Reason that Serenity OS story a few days ago was awesome. However, solutions pushed by corporations with grandiose claims do strike a nerve with me. If only because they are typically pushed with the idea that they will spread through some technical superiority. I'm much more open to this getting more use strictly from w…

Companies using bazel [1]: * Asana * Databricks * Dropbox * Google * Huawei * Lyft * Pinterest * Stripe * TwoSigma * Uber ... This is not a new project that needs pushing. [1] https://github.com/bazelbuild/bazel/wiki/Bazel-Users

This seems silly. If I was to make a similar list of companies using Make, would that have deterred building bazel? Because I guarantee the number was non-zero and included some major players.

Re: Bazel 1.0

#87

Post by indolering »

throwaway1777 wrote: post #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.

There are security reasons to want a reproducible build.

Re: Bazel 1.0

#88

Post by rienbdj »

loeg wrote: post #67
jrockway wrote: post #11

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…

> Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. Pretty much every other build system (e.g., make) is rooted in having a proper dependency graph. This is not a unique property of Bazel.

Make (to use your example) does not do any sandboxing to ensure that the declared dependency graph is actually correct. This is the big innovation in Bazel (and Co).

Re: Bazel 1.0

#89

Post by choppaface »

One of the major time savers of bazel is Remote Build Execution (RBE), which allows you to build modules in parallel in the cloud. So if you have 1000 CPUs, you can really just have a client do `bazel build -j 1000 //...` and you can get a huge speed-up. Remote (and local) builds all happen in a sandbox, so you don't have to worry about e.g. preparing a docker image with the worker / build slave environment. (You do, however, have to register your dependencies with Bazel, which can be a hard at first). To add to this, bazel also has a remote global cache which can benefit large teams.

For fairly large C++ codebases, RBE is really a competitive advantage. I've seen RBE cut down iteration time by an order of magnitude. I love CMake, and CMake can get you plenty of parallelism, but CMake doesn't really provide a tool for building several CMake sub-projects in parallel, and bazel handles this really well.

Sadly Bazel RBE is still primarily a Google Cloud product. Also, GCE is slow to work on supporting auto-scale, so you have to pay for unused workers. (Like most products in Google Cloud, Google is ripping you off with alpha-quality stuff). There's some very rough open source RBE stuff on Github that you can run yourself, but nothing really production-grade yet.

gg ( https://github.com/StanfordSNR/gg ) is a promising-looking alternative. It's research code, but it might be the community's best hope for a non-Google alternative (that e.g. supports AWS Lambda for parallelism). Bazel is great, but without independence (e.g. what Kubernetes achieved) it's difficult to see bazel as dependable as make or CMake long term.

Post reply on HN