[sunshowers]

(I worked on source control at FB for many years.)

The main argument for not overly genericizing things is that you can deliver a better user experience through domain-specific code.

For Bazel and buck2 specifically, they require a total commitment to it, which implies ongoing maintenance work. I also think the fact that they don't have open governance is a hindrance. Google's and Meta's internal monorepos make certain tradeoffs that don't quite work in a more distributed model.

Bazel is also in Java I believe, which is a bit unfortunate due to process startup times. On my machine, `time bazelisk --help` takes over 0.75 seconds to run, compared to `time go --help` which is 0.003 seconds and `time cargo --help` which is 0.02 seconds. (This doesn't apply to buck2, which is in Rust.)

[jeffbee]

This is likely because you are running it in some random PWD that doesn't represent a bazel workspace. When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time.

Running bazel outside of a bazel workspace is not a major use-case that needs to be fixed.

[thayne]

> When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time.

It still has a slow startup time, bazel just works around that by using a persistent daemon, so that it is relatively fast after as long as the daemon is running.

[sunshowers]

That's good to know, thank you!

Do you encounter cache invalidation bugs with daemonization often? I've had pretty bad experiences with daemonized dev tools in the past.

[jrockway]

Bazel prints a message when you invalidate the in-memory cache in a perhaps accidental way; you can supply it with a flag to make this an error and skip the cache invalidation.

If you try to run two Bazel invocations in parallel in the same workspace, one waits for the other to be done.

[jeffbee]

I assumed they meant an error of improperly using cached results. I am sure bazel has its flaws but it assiduously avoids that.

[sunshowers]

I did mean improperly using cached results. It's merely the hardest problem in computer science :)

The sibling suggests this may still be an issue. I'm not surprised—cache invalidation is very difficult to solve, and conservative approximations like tearing down the whole process each time tend to be quite effective.

[__float]

Yes, unless you're using persistent workers. Then you may very well run into the same issues they mention.

[spockz]

GraalVM’s native image has been a thing for a while now. This could overcome the daemon issue partially. The daemon does more ofc by as it keeps some state in memory. But at least the binary start time is a solved problem in Java land.

[sunshowers]

Why does Bazel not ship a native image by default?

[spockz]

I do not know. I could only find GitHub issues and feature sound offering integration with graalvm for building native apps with Bazel.