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

Bazel 2.0

blog.bazel.build

Post reply on HN
Print view View original

51–60 of 117 posts

Re: Bazel 2.0

#51

Post by ur-whale »

teeray wrote: post #34
theodorejb wrote: post #30

I miss the days when JavaScript frameworks could be built with a simple npm install and executing a Grunt/Gulp file. Now to build Angular I need Yarn, Java, Bazel, and hundreds of megabytes of additional tooling downloaded by the build script. On a slow connection it takes ages to download everything, and even then the build often fails (on Windows I have yet to get it working successfully). Edit: I'm referring to bu…

I miss the days when JavaScript frameworks required only a script tag.

I miss the days when Javascript didn't exist.

Re: Bazel 2.0

#52

Post by lenkite »

teeray wrote: post #34
theodorejb wrote: post #30

I miss the days when JavaScript frameworks could be built with a simple npm install and executing a Grunt/Gulp file. Now to build Angular I need Yarn, Java, Bazel, and hundreds of megabytes of additional tooling downloaded by the build script. On a slow connection it takes ages to download everything, and even then the build often fails (on Windows I have yet to get it working successfully). Edit: I'm referring to bu…

I miss the days when JavaScript frameworks required only a script tag.

Those days are BAAACK. Use Vue ! (The best JS framework in the world!)

import Vue from 'https://unpkg.com/vue@2.6.0/dist/vue.esm.browser.min.js'; new Vue({ ... });

Re: Bazel 2.0

#53

Post by zellyn »

shrewduser wrote: post #33
zellyn wrote: post #15

Earlier quoted context omitted.

If you are an organization with a large enough codebase (especially if it's in a monorepo) that you need a shared remote cache of build artifacts, or remote build sharding and execution, and have multiple languages (even protocol buffers) interacting in complex dependencies, then you should run as fast as you can away from less rigorous Blaze-alikes (Pants, Buck, etc.) straight towards Bazel. Yes, it's complicated, b…

I'll never understand the fascination with mono repo's.

Once you reach a certain size of codebase, you're either going to be investing significantly in making many repositories work together and look a bit like a monorepo, or you're going to be investing significantly in making working on individual parts of a monorepo more efficient and look a bit like an isolated repo.

Both approaches take a huge amount of work and tooling.

The big selling point of a monorepo is that the time and effort taken to follow strict versioning and upgrade discipline for multiple interdependent projects can be somewhat avoided. On the code side.

Re: Bazel 2.0

#54

Post by zellyn »

zellyn wrote: post #53
shrewduser wrote: post #33

Earlier quoted context omitted.

I'll never understand the fascination with mono repo's.

Once you reach a certain size of codebase, you're either going to be investing significantly in making many repositories work together and look a bit like a monorepo, or you're going to be investing significantly in making working on individual parts of a monorepo more efficient and look a bit like an isolated repo. Both approaches take a huge amount of work and tooling. The big selling point of a monorepo is that th…

If you're looking for a magic bullet argument proving that either approach is strictly better, I'm not the person to ask.

Re: Bazel 2.0

#55

Post by jerryr »

dehrmann wrote: post #49
bru wrote: post #31

Earlier quoted context omitted.

Yes, 2 months ago.

Must have some people from the Chrome team working on it.

Not that they can’t also be contributing to Bazel, but I believe that Chrome uses GN.

Re: Bazel 2.0

#56

Post by zellyn »

arianvanp wrote: post #47
moomin wrote: post #38

Earlier quoted context omitted.

Nix also exists...

Nix is not (yet) suitable for fine-grained (read file level) build targets though due to lack of recursive nix and content addressed store. This means you don't have early cut off and mass rebuilds if only one file changes; for example. Both are being worked on actively though.

If I understand it correctly (unlikely), Nix has the degree of purely-functional rigor necessary to do this correctly, right? Sounds like it would eventually be awesome for Bazel usecases.

Re: Bazel 2.0

#57

Post by boris »

ajconway wrote: post #39
ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

> run as fast as you can in the opposite direction But which one? Are there any other (non blaze-like) build systems enabling hermetic (possibly remote) builds and caching? If you don't need these properties and have a mono language project, the language's native build system sure fits and may be a better choice.

There is build2. It has "high-fidelity" (instead of hermetic) builds meaning that besides sources it keeps track of changes to options, compilers, etc. This gives you similar benefits at a fraction of the cost. There is no distributed compilation or caching yet but it's coming. In other benefits, it doesn't need Java or Python (or any other "platform").

Re: Bazel 2.0

#58

Post by jacquesm »

anaphor wrote: post #23
ZeroCool2u wrote: post #22

Earlier quoted context omitted.

Hey Drew, I'm a huge fan and have a lot of respect for your work. I feel like I see the pattern of people on HN being disappointed in some of the tools that come out of Google and other large engineering orgs, when they don't work out really well in orgs that are not operating at the same scale. People have similar complaints about the complexity of other projects that come out of Google. K8s comes to mind as one suc…

They need to do a better job of making the assumptions behind the design of the tools clearer then. Because, from what I can tell, many people get the idea that the path to success is to do what Google does (even knowing about the meme that people just try and copy Google). This doesn't just apply to their software tools, but also to their corporate processes (OKRs, etc).

> the path to success is to do what Google does

This kind of cargo-cult process copying has infested the start-up world and is akin to sending a lot of shirts to the laundromat because that's what rich people do and you want to be rich too.

These things work for large companies because they are large companies. Their problems and associated solutions rarely if ever are a good match for the kind of issues that your average start-up contends with, especially early on in the life cycle.

You and your buddy the first-hire developers are not going to gain anything by copying the Spotify development model, and other examples in that vein.

Re: Bazel 2.0

#59

Post by jacquesm »

steeve wrote: post #17
ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

To each their own I guess. I’ve been using it for the last 2 years, and I am not doing any project again without it. Bazel is not that complex if you start a project with it. Migrating to it and learning it at the same time will be hard though since you’re likely to uncover a lot of skeletons.

This comment is not internally consistent.

Re: Bazel 2.0

#60

Post by habitue »

dehrmann wrote: post #43
ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

I was talking with an engineer who saw two people burn out over Bazel, though the specific gripe was with Scala support. I'd expect first-class languages at Google (C++, Java, Python, Go) to get better support.

The languages themselves have decent support. The problem is that it works great if you code the way Google does internally with all your dependencies vendored. Outside of the googleplex where we have, you know, package managers, bazel adds a ton of complexity and bugginess. The core algorithms are battle-hardened in Google, and the third-party package manager support is a tacked-on afterthought on to the open sourced version.

I don't blame the bazel authors, but the development process it was designed for is not the development process of 99% of companies out there. Maintaining BUILD files for all of your vendored dependencies is expensive for your company. You need a full time team working on it.

Unless hermeticity and build correctness issues are absolutely killing your team's productivity (and at a certain size, they might be!) think twice before adding bazel to your maintenance overheads. You can always move to it later if you need it, and it might be more stable and have a better 3rd party package story by then

Post reply on HN