Live data from Hacker News

Common Expression Language

github.com

1–10 of 111 posts

Re: Common Expression Language

#4

At the end of the README: Disclaimer: This is not an official Google product.

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 Google, that stopped being pushed externally once the primary driver behind it left Google or moved on to other projects.

You can actually read some of the process that a Googler will follow when open sourcing software here: https://opensource.google/docs/releasing/

Re: Common Expression Language

#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.

Re: Common Expression Language

#8
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 an AST on top of YAML a la CloudFormation. Now you're programming in YAML, hurray!

2. Extend your static language with executable features a la Terraform/HCL, basically reinventing (and very badly, at that) more traditional language features

3. Use text templates, a la Helm--now you can generate syntactically invalid configuration! (and absolutely trivially, at that)

4. Use an expression language (familiar, ergonomics) a la Pulumi, Starlark, Nix, Nickel, Dhall, etc

Note that in these conversations, someone inevitably shouts "use the simplest tool for the job!" ignoring that static configuration languages (and options 1-3 above) are strictly more complex for the reusability use cases outlined above.

EDIT: Pulumi isn't an expression language; rather, it lets you use real languages to generate configuration, and these languages often include powerful expression features. AWS's CDK is also in this category.

Re: Common Expression Language

#10
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…

I am with you, I wish the world would just adopt Lua as their config files.
Post reply on HN