[beagle3]

They do, until a configuration endless loop brings down their production system.

This is not really different than C vs Rust, or even Perl regular expressions (unbounded execution time) vs real regular expression. With great powers comes great abilities to shoot yourself in the foot.

The power/guarantee balance is delicate, and you can’t hold the stick at both ends. People will always complain.

[HALtheWise]

This is exactly what the Starlark language was developed to solve, initially for Bazel but also used other places. It's a "full scripting language" but intentionally doesn't (in default configuration) support recursion or unbounded loops, so is deterministic and bounded execution time. I really wish more projects would reach for it as a configuration language.

https://github.com/bazelbuild/starlark

[ssousa666]

I have such mixed feelings about Starlark and Bazel macros. When I write Bazel macros, they're great, the perfect tool for the job. When I encounter macros written by someone else, they are awful, a mistake and the bane of my existence.

[crispyambulance]

A lot of this is a matter of taste and judgement.

In the same way that it's possible to have an xml/json/yaml/toml config that creates despair in those who have to maintain it, a python or bash script can grow into a monster in the basement.

Or, it could be a cogent script that makes its intent and operation obvious. I prefer that when possible.

[xixixao]

The environment around the language can put in limits (on time, number of operations, etc.)

Convex does this well, replacing SQL (somewhat yaml-like sucky old declarative language) with JS/TS but in a well-locked-down environment with limits to ensure one mutation or query doesn’t take down the whole DB.

[VectorLock]

The number of times I've seen a configuration endless loop bring down anything are so few compared to the time wasted on DSLs and having to bend over backwards to do things a first-class programming language can do simply. Same with PCRE I've seen that maybe.. once.