Hacker News Reader

Comment by ashishb | Hacker News Reader

Any advantage for using Bazel for newer languages that have a standardized dependency setup like Go or Rust? Or even for JS/TS, where almost everyone uses npm/pnpm/yarn?

View on HN

Other folks have said “mixed languages” and “monorepos” and I agree; I’ll also add that it incorporates steps like building Docker/OCI images, tarballs, potentially even deb/rpm packages all in one place, and with the same sandboxing and deterministic reproducibility as you get with the base language rules.

Like, “I want an OCI image with these contents” gets you an image with the exact files bit-for-bit from the same source, every time. At least aspirationally.

Cargo workspaces do not support compiling two subprojects for two different targets in a single build invocation. The workaround was (still is?) to use each subproject as a standalone project just for builds. The dependency between these targets is now expressed by the Makefile invoking cargo. This also breaks IDE integrations because your IDE does not know how to ask cargo to pick the right target for each workspace member.

Bazel makes this consistent with platforms [0]. I have not used bazel with Rust but it worked fine for my multi-target C++ builds.

[0] https://bazel.build/extending/platforms

I personally don't use it for Go or Rust, so maybe the answer is "no"? There's no native builder for C++ so the utility of Bazel for that language is more apparent.

If you have mixed-language needs, yes. But if not, standardized setup is far better with IDE integration (mostly, VS code LSP etc).

Talk about Bazel in the context of a specific language is missing the point. Bazel is for huge monorepos that aren't based on a single language so that you can have a common interface for all your code in the monorepo regardless of what language individual bits are written in.

Reply on news.ycombinator.com