|
|
|
|
|
|
by asciimike
2017 days ago
|
|
|
Starlark is Python (thanks Guido!), while CEL is designed specifically to not be Turing complete or have constructs like loops, etc. "CEL evaluates in linear time, is mutation free, and not Turing-complete. This limitation is a feature of the language design, which allows the implementation to evaluate orders of magnitude faster than equivalently sandboxed JavaScript." As mentioned, the goals are security policies (it was first used internally as the Security Rules for Cloud Storage for Firebase and the Cloud Firestore) and proto contracts (e.g. you could define addons to your proto to specify the data matched certain behavior): I forget the exact syntax for the contract, but it looked something like this... ```
message person {
@contract(matches(/* RE2 phone number regex */))
string phone_number = 1;
...
}
``` That data could enforce client side checks as well as be used server side (in different implementation languages). I always wanted to see it combined with the proto to Firebase Security Rules generator (https://firebaseopensource.com/projects/firebaseextended/pro...) to do client and server validation. |
|
|
Sort of. Starlark doesn't (or at least didn't originally) support recursion or while loops or a number of other structures. There's also a few other differences that make starlark "better" for configs (some immutability is different, there's no such thing as a `class`, etc.)
I still support loops in a configuration language
or are better than a lot of the more declarative approaches (such as the various contextual approaches of a number of alternative langs) which get hard to reason about because they represent implicit global state.