3 ms·

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/p

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?

jeffbee 2y ago
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.
phinnaeus 2y ago
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.
liuliu 2y ago
If you have mixed-language needs, yes. But if not, standardized setup is far better with IDE integration (mostly, VS code LSP etc).
mrdomino_ 2y ago
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.
kldx 2y ago
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 https://bazel.build/extending/platforms

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?

jeffbee 2y ago

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.

phinnaeus 2y ago

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.

liuliu 2y ago

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

mrdomino_ 2y ago

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.

kldx 2y ago

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 https://bazel.build/extending/platforms