Bazel Release 1.0 • Hacker News Board

Re: Bazel Release 1.0

#41

Post by javagram » Thu, Oct 10, 2019, 3:13 PM UTC

dgellow wrote: post #27

javagram wrote: post #6

Earlier quoted context omitted.

It’s OSS software not a SaaS. If people use it there will be no deprecation date. You can just fork and continue.

I’m sorry if that sounds harsh, but that’s at best a naive view. In practice you cannot just fork the codebase and continue maintaining it, that has a high cost that a lot of organization cannot afford. It’s technically true that you can fork the project but in practice forking something that big doesn’t really happen without a big player leading the fork (or some motivated people with enough time and money to dedica…

Hence the “if people use it” qualifier.

Companies relying on Bazel would step in and support it. We’ve seen this play out plenty of times before, e.g. Hudson to Jenkins or OpenOffice to LibreOffice, where a popular OSS product loses a corporate sponsor and continues.

Re: Bazel Release 1.0

#42

Post by kronin » Thu, Oct 10, 2019, 3:17 PM UTC

Does anyone have experience building graalvm native images with Bazel? Or quarkus more specifically?

Re: Bazel Release 1.0

#43

Post by skybrian » Thu, Oct 10, 2019, 3:20 PM UTC

boris wrote: post #30

klodolph wrote: post #24

Earlier quoted context omitted.

I’ll take a stab at it, since I’ve done some migrations to Bazel (and also away from Bazel). The comparison to Make and makefiles is good because Make, unlike some other build systems, is mostly declarative. Most of your makefile is going to declare what the inputs and outputs are. If you use Make long enough, there are some obvious improvements you want. Multiple outputs, rebuild when options change, and easier cros…

Bazel (and Bazel-derivatives/alikes) is not unique in fixing all of these problems. For example, there is build2, which is arguably a lighter-weight and closer to make (in spirit, not in syntax) solution (no Java dependency, etc). Here is an intro, if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xht...

I did a quick skim and it doesn't seem to sandbox the build steps like Bazel? Maybe I missed something.

Re: Bazel Release 1.0

#44

Post by fuckyah » Thu, Oct 10, 2019, 3:21 PM UTC

one of the rabbit holes folks tend to get into is that bazel will magically solve their codebase problems. builds may be faster, but how about the IDE? most IDE's are not able to handel huge codebases well :/

Re: Bazel Release 1.0

#45

Post by jingwen » Thu, Oct 10, 2019, 3:23 PM UTC

kronin wrote: post #42

Does anyone have experience building graalvm native images with Bazel? Or quarkus more specifically?

There are Bazel rules for Graal: https://github.com/andyscott/rules_graal

Re: Bazel Release 1.0

#46

Post by skybrian » Thu, Oct 10, 2019, 3:27 PM UTC

javagram wrote: post #6

orangepanda wrote: post #5

Did they announce the deprecation date as well? https://killedbygoogle.com/

It’s OSS software not a SaaS. If people use it there will be no deprecation date. You can just fork and continue.

Bazel is too complex to make this practical for most people. It would be like forking Go.

However, it's unlikely to be abandoned.

Re: Bazel Release 1.0

#47

Post by jonhohle » Thu, Oct 10, 2019, 3:33 PM UTC

klodolph wrote: post #39

habitue wrote: post #35

Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0). The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplem…

> The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplementations. My experience from before Bazel is that reimplementations were the way to go most times you had projects with multiple languages, because the alternatives lead you down dark paths—calling into a separate build system suffers from the same problems as recursive make. What excites me about 1.0 is t…

Amazon’s build system handled this gracefully. Native build tool chains were always used, but wrapped in a relatively thin facade. As long as the buildtool could respond to a `release` target and put artifacts in a well known location it didn’t matter what the underlying implementation was.

The biggest drawback that I could see was all dependencies and tool chain needed to be modeled, but once they were, incremental builds, dependency rebuilds, etc. all Just Worked™.

Getting to that point requires a lot of upfront work, however, which can be hard to justify in smaller groups.

Re: Bazel Release 1.0

#48

Post by beisner » Thu, Oct 10, 2019, 3:39 PM UTC

setheron wrote: post #36

I really want to use it but anything beyond the simple example is difficult to migrate to. I must have read the toolchain pages 10x times but still setting up a custom compiler or even different JDK setup is confusing.

From what I have heard, the toolchain story is being worked on heavily. There are some legacy reasons why toolchains were designed the way they were (mostly due to the fact that Google essentially only uses one compiler for each language, and certain toolchains were implemented natively instead of as plugins), but the confusing semantics are improving! Maybe give it another shot in 6-12 months.

Re: Bazel Release 1.0

#49

Post by c4urself » Thu, Oct 10, 2019, 3:41 PM UTC

habitue wrote: post #35

Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0). The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplem…

Agree. I've been dealing with Python rules for Bazel at work and the default implementation of re-downloading everything with pip became a real pain real fast. Decided to generate the third party py_library with a separate tool instead and much happier for it. As an aside for those looking to start with Bazel, it's worth checking out the BazelBuild Slack -- https://slack.bazel.build/

Re: Bazel Release 1.0

#50

Post by klodolph » Thu, Oct 10, 2019, 3:42 PM UTC

boris wrote: post #30

klodolph wrote: post #24

Earlier quoted context omitted.

I’ll take a stab at it, since I’ve done some migrations to Bazel (and also away from Bazel). The comparison to Make and makefiles is good because Make, unlike some other build systems, is mostly declarative. Most of your makefile is going to declare what the inputs and outputs are. If you use Make long enough, there are some obvious improvements you want. Multiple outputs, rebuild when options change, and easier cros…

Bazel (and Bazel-derivatives/alikes) is not unique in fixing all of these problems. For example, there is build2, which is arguably a lighter-weight and closer to make (in spirit, not in syntax) solution (no Java dependency, etc). Here is an intro, if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xht...

It would be interesting to see how build2 achieves these things (hermeticity, cross-building, shared caches). I can’t see anything in the linked documentation that mentions these problems at all.