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

The next generation of Bazel builds

blogsystem5.substack.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: The next generation of Bazel builds

#61

Post by lostdog »

jeffbee wrote: post #58
lostdog wrote: post #55

Earlier quoted context omitted.

For one, Java programs always take too long to start, and that's not something you want in a program that's supposed to be interactive.

See, that's exactly the type of uncritical statement that will force me to discount the rest of your statements on a whole range of topics. bazelisk help 0.01s user 0.00s system 26% cpu 0.053 total

Takes 1.97s on my machine, which is a lot of time for just showing a help message. Maybe you have the setup where Bazel is staying alive in the background or something?

Re: The next generation of Bazel builds

#63

Post by jeffbee »

lostdog wrote: post #61
jeffbee wrote: post #58

Earlier quoted context omitted.

See, that's exactly the type of uncritical statement that will force me to discount the rest of your statements on a whole range of topics. bazelisk help 0.01s user 0.00s system 26% cpu 0.053 total

Takes 1.97s on my machine, which is a lot of time for just showing a help message. Maybe you have the setup where Bazel is staying alive in the background or something?

Literally everyone who uses bazel uses it client-server as a persistent daemon.

Re: The next generation of Bazel builds

#64

Post by sunshowers »

jeffbee wrote: post #33
hn_go_brrrrr wrote: post #29

Earlier quoted context omitted.

Why do you think this author (a long-time senior Blaze maintainer) believes this? Do you think the Blaze team just not have the necessary expertise?

I have no idea but dismissing Java as not "a real systems language" just isn't a convincing critique.

For example, Java's signal handling is not up to par with systems languages. CLI tools that orchestrate operations need to have high-quality signal handling in order to be robust.

Re: The next generation of Bazel builds

#65

Post by sunshowers »

jeffbee wrote: post #63
lostdog wrote: post #61

Earlier quoted context omitted.

Takes 1.97s on my machine, which is a lot of time for just showing a help message. Maybe you have the setup where Bazel is staying alive in the background or something?

Literally everyone who uses bazel uses it client-server as a persistent daemon.

Demonization introduces a range of potential cache invalidation issues. The issues are solvable, but whose KPIs depend on getting to the bottom of them?

Re: The next generation of Bazel builds

#66

Post by lostdog »

jeffbee wrote: post #63
lostdog wrote: post #61

Earlier quoted context omitted.

Takes 1.97s on my machine, which is a lot of time for just showing a help message. Maybe you have the setup where Bazel is staying alive in the background or something?

Literally everyone who uses bazel uses it client-server as a persistent daemon.

And part of why it's a persistent daemon is because Java is slow to start up.

I'll note that bazelisk is written in Go.

Re: The next generation of Bazel builds

#67

Post by sunshowers »

AtlasBarfed wrote: post #16

Build systems are workflow engines. Workflow engines fundamentally separate and structure code and execution in discrete steps with a graph visualizer (hopefully the graph is acyclical). Maybe it's just a bad example, but the code I saw looked very very unseparated. I understand most people who do builds want start out with the one build file to rule them all model. But ultimately you are dealing with a workflow exec…

You're not wrong about build systems being workflow engines, but in my experience the risk of over-generalizing is a worse user experience. One of the most valuable lessons I've learned in my career is that a clean UX often requires messy abstractions underneath.

Re: The next generation of Bazel builds

#68

Post by mook »

throwaway127482 wrote: post #10

One thing not mentioned is the massive amount of complexity and difficulty involved in Starlark rules. In the next generation of build tools, I really wish Starlark could be replaced with some subset of TypeScript, which would have drastically better IDE support. And I wish the typing would be done in such a way that it's harder to do things that are bad for performance. Starlark is super difficult to read, navigate,…

I worked on a project that used Bazel for a bit (but ended up not being a great fit).

I think the part I hated most about Bazel was the fact that there were in fact two dialects; one for BUILD files and one for .bzl files. The things you do in them are different but the documentation is always vague on what goes where.

Re: The next generation of Bazel builds

#69

Post by IshKebab »

keddad wrote: post #26
IshKebab wrote: post #8

Earlier quoted context omitted.

I agree. The biggest issue with Buck 2 for me (apart from documentation) is the lack of something like bzlmod. There's actually a decent number of modules available for Bazel now: https://registry.bazel.build/all-modules But with Buck2 you're stuck with `http_archive` and vendoring.

Seems like a non-issue to me. I work with a relatively large Bazel monorepo, and we have to vendor pretty much anything anyways. Many 3rd-party rules might need patches to work properly with our custom toolchains/rules. Bzlmod sounds nice for small projects, but for big monorepos within organizations with established processes it is more of a hassle, and I imagine that most Bazel users are not using it for small proj…

Yeah it's more of an issue for small projects. But I don't think Buck/Bazel should be reserved for megarepos with thousands of contributors. Why can't small projects use it?

Re: The next generation of Bazel builds

#70

Post by bloppe »

LegNeato wrote: post #28

As the manager of the original Buck team, rules should not be starlark. They should be `wasm`.

I'm super into the component model but honestly the tooling is still not ready. Basically only LLVM (and really just C) has good enough tooling. The rest of the wasm tool chains are still heavily focused on core modules and if they support components it's only `wasi:cli/run`
Post reply on HN