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
Have you ever seen how Starlark is used in the real world? The rulesets for Bazel and Buck could be described as "scripting". It quite literally automates actions.
I'm not sure what you think the difference is.
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.
IIRC starlark is intentionally NOT turing complete. It doesn't allow recursion, or general loops.
1 reply →
Have you ever seen how Starlark is used in the real world? The rulesets for Bazel and Buck could be described as "scripting". It quite literally automates actions.
Take a look here: https://github.com/facebook/buck2-prelude
Also, you are confusing how bazel uses starlark with starlark itself. It's trivial to expose an open or read_file function.