The kubernetes apiserver allows using CEL in CustomResourceDefinition validation rules: - https://kubernetes.io/docs/reference/using-api/cel/ - https://kubernetes.io/docs/tasks/extend-kubernetes/custom-re...

It also allows using CEL in ValidatingAdmissionPolicies: - https://kubernetes.io/docs/reference/access-authn-authz/vali...

I think apples to apples comparison would be comparing against Rego. To me CEL is more appealing due to its simplicity.

CEL is much more computationally limited as it aims to keep evaluations in the microsecond range.

With OPA you can easily create policies that take tens, hundreds or even thousands of millisecond.

That comes at the expense of a lot of power though, so much of the complex logic that you can write in OPA simply isn't achievable in CEL.

It's not really a configuration language like Jsonnet and CUE. It's an expression language for specifying things like conditions and policies. You _could_ abuse it as a configuration language, but it'd be overkill.

Are you suggesting to compile CEL into native code and run the compiled code at runtime (i.e. as a predicate function)? I think this is doable and I vaguely remember this was how it's implemented initially.

But most use cases are treating CEL as a user provided config, which requires runtime parsing and execution.

A better solution would be first-class metaprogramming, like in Zig or LISP. Maybe with some subset which guarantees to halt (I.e. no unbounded loops, no recursion, no FFI, known input size, hard time limits, etc.)

Query DSLs are designed to simplify query planning by intentionally avoiding certain language features. You have many different choices on how to execute a query - in SQL for example, there's table scans, index seeks/scans, joins, etc. and you can execute them in different order. By being able to analyze the query upfront you can estimate the relative costs of different plans and choose the best one. Less powerful languages result in more predictable estimates because they're simpler to analyze.

It's not fully applicable here, but industry standard DSLs also stick around because non-programmers find learning it a good investment.

I have a business analytics friend that knows SQL because it's part of his workflows.

But Excel, Notion, Power BI, and other low/no-code tools all have their own data filtering and transformation languages (or dialects). He'd rather spend his time learning more about his line of business, than an aspect of yet another cloud tool that gets forced on him.

No, they're equating _Turing completeness_ with _might not terminate_. CEL, Expr, Rego, and other languages like them are intended to guarantee to complete. You can't do that cleanly with a Turing complete language.

Ease/ability to embed in other language safely. Predictability of memory, execution. Known constraints like guaranteed to terminate is useful.

no Doom running on cel.

I recently wanted to expose some basic user auto tagging/labeling based on the json data.

I chose cel, over python, SQL because I could just import the runtime in C++, or any language that implements it (python, js etc..)

Safely running a sandboxed python execution engine is significantly more effort and lower performance.

At this cel excels.

Where it didn't was user familiarity and when the json data itself was complex.

Say “halting problem” without saying “halting problem” ;)

There is a practical solution to it called “metering”, like gas mechanism in Ethereum’s EVM or cost calculation for complex GraphQL queries.

What you really want is "can be completed after a certain amount of time", not "can be cancelled". You don't want iam policy rules to be skipped because they took too long.