Re:Go 1.24's go tool is one of the best additions to the eco...
by jeffbee on Monday January 27, 2025 @06:01PM
(#42846810)
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.
Re:Go 1.24's go tool is one of the best additions to the eco...
by sunshowers on Monday January 27, 2025 @06:10PM
(#42846887)
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.
Re:Go 1.24's go tool is one of the best additions to the eco...
by jrockway on Monday January 27, 2025 @08:31PM
(#42847915)
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.
Re:Go 1.24's go tool is one of the best additions to the eco...
by jeffbee on Monday January 27, 2025 @08:41PM
(#42847991)
I assumed they meant an error of improperly using cached results. I am sure bazel has its flaws but it assiduously avoids that.
Re:Go 1.24's go tool is one of the best additions to the eco...
by __float on Monday January 27, 2025 @10:10PM
(#42848479)
Yes, unless you're using persistent workers. Then you may very well run into the same issues they mention.
Re:Go 1.24's go tool is one of the best additions to the eco...
by sunshowers on Tuesday February 04, 2025 @02:58PM
(#42937743)
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.
Re:Go 1.24's go tool is one of the best additions to the eco...
by thayne on Tuesday January 28, 2025 @12:29AM
(#42849156)
> 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.
Re:Go 1.24's go tool is one of the best additions to the eco...
by spockz on Tuesday January 28, 2025 @01:40AM
(#42849535)
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.
Re:Go 1.24's go tool is one of the best additions to the eco...
by sunshowers on Tuesday February 04, 2025 @02:59PM
(#42937765)
Why does Bazel not ship a native image by default?
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.)