Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
prometheus-operator
Prometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
skycfg
Skycfg is an extension library for the Starlark language that adds support for constructing Protocol Buffer messages.
-
mina
Mina is a cryptocurrency protocol with a constant size blockchain, improving scaling while maintaining decentralization and security. (by MinaProtocol)
-
adventofcode
Advent of Code solutions of 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 and 2023 in Scala (by sim642)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I think it might still have issues figuring out that it needs to apply CRDs first: https://github.com/grafana/tanka/issues/246 Besides that, I found it super-handy for deploying https://github.com/prometheus-operator/prometheus-operator and https://github.com/kubernetes-monitoring/kubernetes-mixin
https://carvel.dev/ytt/
ytt lets you embed logic via a python-subset (starlark) and also provides "overlays" as a "replace/insert" mechanism. and all valid ytt files are valid yaml files, so they can be passed-through other yaml parsing stages.
Dhall is my favorite configuration language that I never get around to using.
I manage DNS in Terraform, and since every Terraform provider uses different objects definitions, and every object definition is rather verbose, Dhall would be a way to specify my own DRY types and leave the provider-specific details in one place. Adding new DNS entries and moving several domains between providers would be a matter of changing fewer lines.
Dhall also has Kubernetes bindings:
https://github.com/dhall-lang/dhall-kubernetes
Although I'm tempted to just stick to Helm here, even though it's less type-safe.
Comparison with a related language (perhaps biased, since opinion is from creator of that language).
"Comparisons between CUE, Jsonnet, Dhall, OPA, etc." https://github.com/cue-lang/cue/discussions/669
Comparison of similar projects, including Dhall:
https://github.com/oilshell/oil/wiki/Survey-of-Config-Langua...
I think it might still have issues figuring out that it needs to apply CRDs first: https://github.com/grafana/tanka/issues/246 Besides that, I found it super-handy for deploying https://github.com/prometheus-operator/prometheus-operator and https://github.com/kubernetes-monitoring/kubernetes-mixin
I think it might still have issues figuring out that it needs to apply CRDs first: https://github.com/grafana/tanka/issues/246 Besides that, I found it super-handy for deploying https://github.com/prometheus-operator/prometheus-operator and https://github.com/kubernetes-monitoring/kubernetes-mixin
Have you seen Starlark? It's not too far from that, but safer in a number of ways: https://github.com/bazelbuild/starlark
Can you say more about what GCL does better than all of the open source ones?
Anecdotally, I've heard a lot of GCL horror stories, and many Xooglers have chosen to create things like Jsonnet or Skycfg (https://github.com/stripe/skycfg) instead.
I have been writing a fair amount of Dhall using autogenerated CloudFormation bindings ( https://github.com/jcouyang/dhall-aws-cloudformation/ ). It is a fantastic way to reduce boilerplate and factor out recurring blobs. My main frustration is that the type checker is not smart enough (or maybe the type system is undecidable?) - every time you want to use a polymorphic function, you must pass in the type parameters yourself (this is also true for empty lists and `None`). This makes simple FP idioms extremely noisy, to the point where you're better off writing longhand. In a language that's meant to be alleviating YAML/JSON boilerplate.
It's still a massive improvement, but it could be so much better if the typechecker was smarter.
I usually try Advent of Code (https://adventofcode.com) every year with a new language I'm interested in. So far it's allowed me to get respectable knowledge of:
We use https://github.com/octodns/octodns for some of our DNS records. It's flexible, much faster than Terraform for thousands of records, and the maintainer Ross has been responsive on issues and pull requests. Also see Cloudflare's blog for how they use it
> jsonnet seemed like a great idea to me, but I've experienced extremely low performance.
Although each implementation of jsonnet has some quirks, take a look at (scala-based) sjsonnet^1 or go-jsonnet^2 for improved performance. We use go-jsonnet because of some issues we had with the scala version - but it does seem to be the fastest by a large margin.
There's also a Rust version^3 that claims to be the fastest yet^4, but I haven't experimented with it at all.
[1]: https://github.com/databricks/sjsonnet
[2]: https://github.com/google/go-jsonnet/
[3]: https://github.com/CertainLach/jrsonnet
[4]: https://gist.github.com/CertainLach/5770d7ad4836066f8e0bd91e...
> jsonnet seemed like a great idea to me, but I've experienced extremely low performance.
Although each implementation of jsonnet has some quirks, take a look at (scala-based) sjsonnet^1 or go-jsonnet^2 for improved performance. We use go-jsonnet because of some issues we had with the scala version - but it does seem to be the fastest by a large margin.
There's also a Rust version^3 that claims to be the fastest yet^4, but I haven't experimented with it at all.
[1]: https://github.com/databricks/sjsonnet
[2]: https://github.com/google/go-jsonnet/
[3]: https://github.com/CertainLach/jrsonnet
[4]: https://gist.github.com/CertainLach/5770d7ad4836066f8e0bd91e...
> jsonnet seemed like a great idea to me, but I've experienced extremely low performance.
Although each implementation of jsonnet has some quirks, take a look at (scala-based) sjsonnet^1 or go-jsonnet^2 for improved performance. We use go-jsonnet because of some issues we had with the scala version - but it does seem to be the fastest by a large margin.
There's also a Rust version^3 that claims to be the fastest yet^4, but I haven't experimented with it at all.
[1]: https://github.com/databricks/sjsonnet
[2]: https://github.com/google/go-jsonnet/
[3]: https://github.com/CertainLach/jrsonnet
[4]: https://gist.github.com/CertainLach/5770d7ad4836066f8e0bd91e...