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

131–140 of 204 posts

Re: Bazel 1.0

#131

Post by cromwellian »

jhasse wrote: post #120
cromwellian wrote: post #75

Earlier quoted context omitted.

Java starts up in ~1s, something like Graal could make this faster. But I find this Java criticism more a symptom of Java-derangement syndrome, because python and node build systems have even worse startup times and no one says anything.

> python and node build systems have even worse startup times and no one says anything. Noop build with Waf (build system written in Python) takes 0.13s on my system. Waf reports that the build actually takes 0.04s, so I guess 0.09s is Python's start-up time (and some other overhead).

Java Hello World takes 0.132s on my Macbook pro. If I turn on -Xshare:on to use class data sharing, then it drops to 0.119s. Ergo, Java startup time is non-factor. Graal could make this even quicker, for example, a GraalVM AOT helloworld can be reduced to .008s startup, see https://github.com/graalvm/graalvm-demos/tree/master/java-ko... for example.

"time bazel" returns 0.098s

Running a null build took 0.84s, but Bazel does significantly more work, as it's working on a big monorepo, as both a build tool and a package manager.

In short, it is not a problem. But I've had npm take many many seconds for simple operations. "npm list" takes 2.9 seconds.

Python can be slow, depending on the tool. Waf sounds like it is simple and fast, but there are lots of other examples of slow python frameworks out there.

Re: Bazel 1.0

#132

Post by beagle3 »

londons_explore wrote: post #111
amelius wrote: post #105

Earlier quoted context omitted.

> Especially if you can't or don't want to use memory mapping because it's hard to do well. Why do new languages never address this issue?

In-kernal block caching of files is pretty crude - since the kernel has no knowledge of your data structures or which bits of your files you're going to be reading next, you end up having hundreds of page faults requiring single-sector disk reads for most workloads.

That’s often the case if your file format evolves without taking a mmap use case into account. But for a format that’s designed with mmapping in mind, it is often ridiculously faster and more effective.

But most languages and environments don’t let you do that easily.

Re: Bazel 1.0

#133

Post by cromwellian »

fnord123 wrote: post #108
sz4kerto wrote: post #82

Earlier quoted context omitted.

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

JVM startup for `java -version` is around 150ms on my machine: $ time java -version openjdk version "11.0.1" 2018-10-16 OpenJDK Runtime Environment 18.9 (build 11.0.1+13) OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode) real 0m0.159s user 0m0.116s sys 0m0.052s This is how long it takes for a program like git to do actual work. Once you start running an actual program like Maven, it blows up to 500ms for `m…

With Graal AOT you can make command line utilities that start on the order of 0.008s

https://github.com/graalvm/graalvm-demos/tree/master/java-ko...

Re: Bazel 1.0

#134

Post by beagle3 »

taeric wrote: post #85
klodolph wrote: post #39

Earlier quoted context omitted.

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,…

But the problem is that there were no proper build systems to use, not that they weren’t familiar with them.

Gmake, cmake, scons, waf, whatever - non of them provide hermetic deterministic builds, track compiler versions properly, etc.

The only build system I had used which could, with crazy effort, provide some of those features, is iirc ClearCase (or whatever it used for version control and management), and it was painful in every way and still didn’t enforce it - just had enough to allow you to do it with great effort (which gmake/cmake don’t even do)

Re: Bazel 1.0

#135

Post by pjmlp »

fnord123 wrote: post #108
sz4kerto wrote: post #82

Earlier quoted context omitted.

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

JVM startup for `java -version` is around 150ms on my machine: $ time java -version openjdk version "11.0.1" 2018-10-16 OpenJDK Runtime Environment 18.9 (build 11.0.1+13) OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode) real 0m0.159s user 0m0.116s sys 0m0.052s This is how long it takes for a program like git to do actual work. Once you start running an actual program like Maven, it blows up to 500ms for `m…

Java 13 takes 97ms on Windows 10, and I haven't bothered to produce a Java native image before attempting it.

    PS C:\Workdir> Measure-Command { java -version }
    openjdk version "13" 2019-09-17
    OpenJDK Runtime Environment (build 13+33)
    OpenJDK 64-Bit Server VM (build 13+33, mixed mode, sharing)


    Days              : 0
    Hours             : 0
    Minutes           : 0
    Seconds           : 0
    Milliseconds      : 97
    Ticks             : 975572
    TotalDays         : 1.12913425925926E-06
    TotalHours        : 2.70992222222222E-05
    TotalMinutes      : 0.00162595333333333
    TotalSeconds      : 0.0975572
    TotalMilliseconds : 97.5572
About 60 ms more than make.

Hurray Make still wins, now what are we going to do with those 60ms... /s

Re: Bazel 1.0

#136

Post by brown9-2 »

bradfitz wrote: post #25
paulddraper wrote: post #19

Earlier quoted context omitted.

Parts of Bazel are written in C/C++. The command line client as well as some low level file utilities. But Bazel is distributed as a standalone package in several packaging systems; no need to install Java yourself. Though I doubt many people know this; there's virtually no reason you would be exposed to its language implementation choices. EDIT: Actually I believe Bazel is changing its .deb package to not be standal…

> there's virtually no reason you would be exposed to its language implementation choices Um, doesn't it still have a client that starts up a persistent server and you then have to wait for that server to start up (which, being Java, takes forever) and then deal with those server processes hanging around? That sounds like being exposed to its language implementation choices. As opposed to, say, having fast start-up t…

The server shuts itself down after some idle time, I’ve never had to actively manage any instances of it.

Re: Bazel 1.0

#137

Post by AsyncAwait »

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

Eh, static binaries solve this & Gradle presents plenty of potential problems in my experience.

Re: Bazel 1.0

#138

Post by G2H »

bazza451 wrote: post #73

Does anyone know of a real beginners level guide to Bazel that isn’t the docs. Got a typescript monorepo with a few backend services/react frontends I wanted to build and I got a bit lost in the complexity of it due to package.json handling

We wrote a bit about how we build a TS monorepo with Bazel on our company's blog [1] if that can be helpful

[1] https://dataform.co/blog/typescript-monorepo-with-bazel/

Re: Bazel 1.0

#139

Post by jhasse »

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

Is that such a big issue though ? The default install of my dev machine (Ubuntu) installed two different versions of python and perl5, neither of which I use. Other languages have been installed indirectly because I installed one tool or another. As long as the language itself doesn't get in the way (e.g. the tool is picky about the language version and requires extra work to install it) why should I care ?

I bet you're using Python and Perl indirectly, because lots of Ubuntu's tools are written in those languages.

Re: Bazel 1.0

#140

Post by adgasf »

emelski wrote: post #91
rienbdj wrote: post #88

Earlier quoted context omitted.

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).

Electric Make has had sandboxing since 2002, no conversion from your familiar make-based builds to a new shiny build tool required, and it can make on-the-fly corrections to execution order if that sandboxing reveals that incomplete dependency specifications caused something to run in the wrong order (relative to a strictly serial build). "Sandboxing" in a build tool cannot be claimed as Bazel's innovation.

Can you link to the project?
Post reply on HN