bazel

Somehow this keeps happening https://github.com/bazelbuild/bazel/issues/15515

Bazel uses neither of those; Bazel's Starlark interpreter (which is the original Starlark implementation, predating the Go and Rust ones) is written in Java. It hasn't been extracted into a standalone library with a stable API, so only Bazel can really use it. https://github.com/bazelbuild/bazel/tree/master/src/main/jav...

Chicory seems like it'll be pretty useful. Java doesn't have easy access to the platform-specific security mechanisms (seccomp, etc) that are used by native tools to sandbox their plugins, so it's nice to have WebAssembly's well-designed security model in a pure-JVM library. I've used it to experiment with using WebAssembly to extend the Bazel build system (which is written in Java). Currently there are several Bazel rulesets that need platform-specific helper binaries for things like parsing lock files or Cargo configs, and that's exactly the kind of logic that could happily move into a WebAssembly blob. https://github.com/jmillikin/upstream__bazel/commits/repo-ru... https://github.com/bazelbuild/bazel/discussions/23487

> Bazel also obviously uses the system compilers and headers. Nix does not. Bazel allows hermetic toolchains, and uses it for most languages: Java, Python, Go, Rust, Node.js, etc. You can do the same for C++, but Bazel doesn't provide that out-of-the-box. [1] Bazel sandboxing can restrict system access on Linux with --experimental_use_hermetic_linux_sandbox and --sandbox_add_mount_pair. [2] Every "reproducible builds" discussion requires an understand of what is permitted to vary. E.g. Neither Nix nor Bazel attempts to make build products the same for x86 host environments vs ARM host environments. Bazel is less aggressive than Nix in that it does not (by default) attempt to make build products the same for different host C++ compilers. [1] https://github.com/bazelbuild/bazel/discussions/18332 [2] https://bazel.build/reference/command-lin

You can say that for everything, after all if it's turing complete you can do anything. But practically, the difference is intention, which drives design and ecosystem. E.g: starlark is very oriented toward idempotence and limiting side effects to get reproducible config data. By default they discourage reading files: https://github.com/bazelbuild/bazel/issues/13300 But rhai is not particularly oriented toward config, and the doc promotes an extension to read files: https://rhai.rs/book/lib/rhai-fs.html The tutorials, stdlib, language design anf tooling will all reflect this. You probably don't want to use starlark to automate much action, but it will be well suited to describe states.