Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Expression Language

github.com

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Common Expression Language

#31

Post by kyrra »

neolog wrote: post #17
kyrra wrote: post #4

Earlier quoted context omitted.

I'm a Googler, opinions are my own. A lot of the times engineers at Google will open source libraries or tools they have worked on, which go under the Google GitHub repo, but are attached with that language. This is basically saying that it is owned by Google but it is not something Google is officially supporting. It may continue to get updates, it may not. I've definitely seen some libraries open sourced from Googl…

What is the significance to a user of whether Google is "officially supporting" a product or not?

If it's not officially supported, it probably means it's just one or two people that open sourced it, and it would fall on them to keep it in sync with any internal work.

Officially supported means it's actually owned by some team. They'll dedicate resources to it, meaning it will be accounted for on any project planning or resource management the management needs to do.

Officially supported things tend to be bigger.

Re: Common Expression Language

#32

Post by shawnz »

asciimike wrote: post #16
frou_dh wrote: post #5

I remember seeing this used inside config files for the Caddy webserver. Google seem to like these executable config languages because they've got another open source one ("Starlark") a few notches up in expressivity.

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 (i…

Starlark is also designed specifically to not be Turing complete (it is only a subset of Python).

Re: Common Expression Language

#33

Post by contravariant »

chc4 wrote: post #23
contravariant wrote: post #15

I'd be a bit suspicious about the claim that it is not Turing complete. To be fair I can't yet find a way to allow arbitrary computation (though it seems easy to add one with fairly innocuous features). Although you can get it to solve 3-SAT, though only for some predefined number of variables (which it assures can be at least 32). Combinatorics stuff like printing all possible sudokus also seems like it should be fe…

There's a difference between pathologically high complexity functions and Turing completeness. Sub-Turing languages generally don't allow recursion or unbounded loops - your program is always making progress. Solving 3-SAT doesn't sound like it precludes sub-Turing completeness, since you'd have a finite number of solutions you're iterating over. It's still useful for a config language because it makes it harder to a…

On the one hand you're right, though at some point 'arbitrarily long' and Turing complete become pretty similar. In fact an ordinary computer isn't entirely a Turing machine either, as its memory is limited.

Also it means you need to be careful about malicious input, you need to take countermeasures when you evaluate an expression from an untrusted source.

Re: Common Expression Language

#34

Post by latchkey »

throwaway894345 wrote: post #8
frou_dh wrote: post #5

I remember seeing this used inside config files for the Caddy webserver. Google seem to like these executable config languages because they've got another open source one ("Starlark") a few notches up in expressivity.

I'm an ardent supporter of executable config languages, especially for the infrastructure-as-code space (the only thing special about this space is that configs tend to be very large, so you're more likely to run into reuse issues), which markets itself as "it's just YAML!" but inevitably all of that copy/pasted YAML becomes unwieldy and you want reusability. At that point, you have a few distinct options: 1. Build a…

From point 1, this is my favorite wat example in ansible...

  - file:
      path: /etc/foo.conf
      owner: foo
      group: foo
      mode: 0644

Re: Common Expression Language

#36

Post by closeparen »

azurezyq wrote: post #22
neolog wrote: post #17

Earlier quoted context omitted.

What is the significance to a user of whether Google is "officially supporting" a product or not?

E.g., if google is obliged to address your bugs / issues. It matters a lot in enterprise. This statement is more like a waiver you'd like to sign while using some entertainment equipements.

An open source maintainer is never obligated to address your bugs / issues. However it is good open source citizenship to be clear about what level of support people can and can't expect.

Re: Common Expression Language

#37

Post by blonde_ocean »

chc4 wrote: post #23
contravariant wrote: post #15

I'd be a bit suspicious about the claim that it is not Turing complete. To be fair I can't yet find a way to allow arbitrary computation (though it seems easy to add one with fairly innocuous features). Although you can get it to solve 3-SAT, though only for some predefined number of variables (which it assures can be at least 32). Combinatorics stuff like printing all possible sudokus also seems like it should be fe…

There's a difference between pathologically high complexity functions and Turing completeness. Sub-Turing languages generally don't allow recursion or unbounded loops - your program is always making progress. Solving 3-SAT doesn't sound like it precludes sub-Turing completeness, since you'd have a finite number of solutions you're iterating over. It's still useful for a config language because it makes it harder to a…

How do you mean sub-Turing languages don’t allow recursion? Aren’t context-free languages, for example, literally recursive?

Re: Common Expression Language

#38

Post by rossjudson »

frou_dh wrote: post #5

I remember seeing this used inside config files for the Caddy webserver. Google seem to like these executable config languages because they've got another open source one ("Starlark") a few notches up in expressivity.

It's not really a config language. It's directed at fast execution of expressions and being able to provide some measure of type safety.

Re: Common Expression Language

#40

Post by B-Con »

neolog wrote: post #17
kyrra wrote: post #4

Earlier quoted context omitted.

I'm a Googler, opinions are my own. A lot of the times engineers at Google will open source libraries or tools they have worked on, which go under the Google GitHub repo, but are attached with that language. This is basically saying that it is owned by Google but it is not something Google is officially supporting. It may continue to get updates, it may not. I've definitely seen some libraries open sourced from Googl…

What is the significance to a user of whether Google is "officially supporting" a product or not?

"Official" is mostly about who they consider the customers of the product when making a decision.

If the project is officially open-sourced, that will be taken into consideration when project priorities, re-orgs, and direction occur at higher levels. "How does this effect our commitment to the community" is a question to address. If it isn't official, then is best-effort by the people who pushed for it to go open-source.

Post reply on HN