4 ms·

It seems weird to require an entirely new programming language for this tbh. They make the claim that it is special because it's not Turing-complete, but that's

It seems weird to require an entirely new programming language for this tbh. They make the claim that it is special because it's not Turing-complete, but that's nonsense. Turing completeness is almost never a property that is important. I think in this case they're equating Turing incompleteness with "doesn't take a long time to execute" but that isn't really the case at all. The property you really want is "can be cancelled after a certain amount of compute time - ideally a deterministic amount", and you can obviously do that with Turing complete languages.

joshuamorton 9mo ago
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.
- IshKebab 9mo ago
  Well CEL doesn't offer that guarantee. For any given "certain amount of time" you can write a CEL filter that takes longer.
  - dilyevsky 9mo ago
    See my other comment - you can refuse to accept CEL filters that take too long to begin with.
  - joshuamorton 9mo ago
    Correct, but you can also reject filters that will take longer statically. The point is not "any arbitrary CEL program will run in less than 10us", it's that I can encode "do not allow filters that take more than 10us to evaluate" an then have a very high degree of confidence that that will be true for any user provided filter that is accepted (and if I'm wrong it'll be...11us, not 5s) In the common use-cases for CEL that I've seen, you don't want to skip evaluation and fail open or closed arbitrarily. That can mean things like "abusive user gets access to data they should not be allowed to access because rule evaluation was skipped". You also may have tons of rules and be evaluating them very often, so speed is important.
talideon 9mo ago
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.
- IshKebab 9mo ago
  Right but "guaranteed to terminate" is not a useful property. You could write a program that terminates... after a billion years.
  - dilyevsky 9mo ago
    You can estimate cost of CEL program using static analysis before running it. "estimate" only because size of runtime data is generally unknown (but obv you could limit that).
    - IshKebab 9mo ago
      "You can" - in theory, or does this actually exist?
      - dilyevsky 9mo ago
        https://pkg.go.dev/github.com/google/cel-go/cel#Env.EstimateCost https://pkg.go.dev/github.com/google/cel-go/cel#Env.Estimate...
      - AlecBG 9mo ago
        With certain macros disabled like .map the runtime is O(code length)!
      - akshayshah 9mo ago
        There’s a whole section on this on TFA: https://celbyexample.com/execution-cost/ https://celbyexample.com/execution-cost/
aleksiy123 9mo ago
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.
- IshKebab 9mo ago
  > Known constraints like guaranteed to terminate is useful. "Guaranteed to terminate" actually means "guaranteed to terminate in finite but possibly arbitrarily large time" which is really not a useful property. There's no practical difference between a filter that might take 1 billion years to run and one that might take more than a billion years.
  - aleksiy123 9mo ago
    Yes but when you combine it with the other guarantees on performance. https://github.com/google/cel-spec/blob/master/doc/langdef.md#performance-limits https://github.com/google/cel-spec/blob/master/doc/langdef.m... And your service puts an upper bound on input size and cel expression size. (True for all practical applications.) You can actually get a guarantee tha t you can't construct a billion year expression. And even guarantee that all expressions will evaluate in let's say 60 secs. Turing completeness by itself does not guarantee this but it is a necessary prerequisite for these guarantees.
    - IshKebab 9mo ago
      > Turing completeness by itself does not guarantee this They should update their home page then!
nxobject 9mo ago
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.
nivertech 9mo ago
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.
- IshKebab 9mo ago
  Yeah I think it's typically called "fuel".
pverheggen 9mo ago
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.

joshuamorton 9mo ago

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.

IshKebab 9mo ago
Well CEL doesn't offer that guarantee. For any given "certain amount of time" you can write a CEL filter that takes longer.
- dilyevsky 9mo ago
  See my other comment - you can refuse to accept CEL filters that take too long to begin with.
- joshuamorton 9mo ago
  Correct, but you can also reject filters that will take longer statically. The point is not "any arbitrary CEL program will run in less than 10us", it's that I can encode "do not allow filters that take more than 10us to evaluate" an then have a very high degree of confidence that that will be true for any user provided filter that is accepted (and if I'm wrong it'll be...11us, not 5s) In the common use-cases for CEL that I've seen, you don't want to skip evaluation and fail open or closed arbitrarily. That can mean things like "abusive user gets access to data they should not be allowed to access because rule evaluation was skipped". You also may have tons of rules and be evaluating them very often, so speed is important.

talideon 9mo ago

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.

IshKebab 9mo ago
Right but "guaranteed to terminate" is not a useful property. You could write a program that terminates... after a billion years.
- dilyevsky 9mo ago
  You can estimate cost of CEL program using static analysis before running it. "estimate" only because size of runtime data is generally unknown (but obv you could limit that).
  - IshKebab 9mo ago
    "You can" - in theory, or does this actually exist?
    - dilyevsky 9mo ago
      https://pkg.go.dev/github.com/google/cel-go/cel#Env.EstimateCost https://pkg.go.dev/github.com/google/cel-go/cel#Env.Estimate...
    - AlecBG 9mo ago
      With certain macros disabled like .map the runtime is O(code length)!
    - akshayshah 9mo ago
      There’s a whole section on this on TFA: https://celbyexample.com/execution-cost/ https://celbyexample.com/execution-cost/

aleksiy123 9mo ago

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.

IshKebab 9mo ago
> Known constraints like guaranteed to terminate is useful. "Guaranteed to terminate" actually means "guaranteed to terminate in finite but possibly arbitrarily large time" which is really not a useful property. There's no practical difference between a filter that might take 1 billion years to run and one that might take more than a billion years.
- aleksiy123 9mo ago
  Yes but when you combine it with the other guarantees on performance. https://github.com/google/cel-spec/blob/master/doc/langdef.md#performance-limits https://github.com/google/cel-spec/blob/master/doc/langdef.m... And your service puts an upper bound on input size and cel expression size. (True for all practical applications.) You can actually get a guarantee tha t you can't construct a billion year expression. And even guarantee that all expressions will evaluate in let's say 60 secs. Turing completeness by itself does not guarantee this but it is a necessary prerequisite for these guarantees.
  - IshKebab 9mo ago
    > Turing completeness by itself does not guarantee this They should update their home page then!

nxobject 9mo ago

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.

nivertech 9mo ago

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.

IshKebab 9mo ago
Yeah I think it's typically called "fuel".

pverheggen 9mo ago

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.