SaaSHub helps you find the best software and product alternatives Learn more →
Dhall-lang Alternatives
Similar projects and alternatives to dhall-lang
-
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
terraform
Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
-
-
-
-
-
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
dhall-lang discussion
dhall-lang reviews and mentions
-
I no longer have an old-school cert on my HTTPS site
Fixing all of those at once might be a bit too much to ask, but I have some quick suggestions. I'd say for a more robust JSON you could try Dhall. If you just want to exchange lumps of data between programs I'd use Protobuf. If you want simple and freeform I'd go with good old sexps.
https://github.com/dhall-lang/dhall-lang
- Dhall: Programmable Config Language a.k.a.
-
Any program can be a GitHub Actions shell
I'll give a shot at some guiding principals:
1. Do not use yaml.
All github action logic should be written in a language that compiles to yaml, for example dhall (https://dhall-lang.org/). Yaml is an awful language for programmers, and it's a worse language for non-programmers. It's good for no one.
2. To the greatest extent possible, do not use any actions which install things.
For example, don't use 'actions/setup-node'. Use bazel, nix, direnv, some other tool to setup your environment. That tool can now also be used on your developer's machines to get the same versions of software as github.
3. Actions should be as short and simple as possible.
In many cases, they will be as simple as effectively "actions/checkout@v4", "run: ./ci/build.sh", and that's it.
4. Do not assume that things are sane or secure by default.
Ideally you don't accept PRs from untrusted users, but if you do, read all the docs very carefully about what actions can run where, etc. Github actions on untrusted repos are a nightmare footgun.
- The Dhall Configuration Language
-
StrictYAML
I'm a fan of anything that moves us away from stringly typed nonsense.
See also Dhall (which can render to yaml). I like the idea but found the veneer broke a little too often and left me squinting at Haskell.
https://dhall-lang.org/
-
Some Programming Language Ideas
I think you're asking for Starlark (https://starlark-lang.org), a language that strongly resembles Python but isn't Turing-complete, originally designed at Google for use in their build system. There's also Dhall (https://dhall-lang.org), which targets configuration use cases; I'm less familiar with it.
One problem is that, while non-Turing-completeness can be helpful for maintainability, it's not really sufficient for security. Starlark programs can still consume exponential amounts of time and memory, so if you run an adversary's Starlark program without sandboxing it, you're just as vulnerable to denial-of-service attacks as you'd be with a Turing-complete language. The most common solution is sandboxing, wherein you terminate the program if it exceeds time or memory limits; however, once you have that, it's no longer necessary for the language to not be Turing-complete, so you might as well use a popular mainstream language that's easy to sandbox, like JavaScript.
One other intriguing option in the space is CEL (https://cel.dev), also designed at Google. This targets use cases like policy engines where programs are typically small, but need to be evaluated frequently in contexts where performance matters. CEL goes beyond non-Turing-completeness, and makes it possible to statically verify that a program's time and space complexity are within certain bounds. This, combined with the lack of I/O facilities, makes it safe to run an adversary's CEL program outside a sandbox.
-
8 months of OCaml after 8 years of Haskell in production
> Lambda calculus is as pure as can be, and also has terms that don't normalize. That is not considered a side effect.
Many typed lambda calculi do normalise. You can also have a look https://dhall-lang.org/ for some pragmatic that normalises.
> A better example of impurity in Haskell for pragmatic's sake is the trace function, that can be used to print debugging information from pure functions.
Well, but that's just unsafePerformIO (or unsafePerformIO-like) stuff under the hood; that was already mentioned.
-
Thoughts on ThoughtWorks Radar 2024
I was first turned onto Pkl during my Dhall Trough of Disillusionment phase (Dhall is cool, but man is it hard) by James Ward. It looked to be a language that had enough types to compile YAML/JSON configuration files wayyyy more safely. I’ve had enough YAML/JSON misconfigurations break production, that I started looking into ways to compile those problems away, and Dhall helped a lot, but the learning curve and compiler errors are brutal to work through, and I never got excitement amongst peers. Hoping Pkl makes in-roads here.
-
Adding algebraic data types to Nickel
Dhall[1] also usually gets mentioned in the same sentence as CUE.
As for Nickel, I have mixed feelings about it of the same kind as about ES6 classes and perhaps modules—we’re taking a simple language (an extremely simple one, in the case of Nix) and baking into it some stuff that the original had as a completely satisfactory library, in the name of discoverability resp. uniformity. Seems a bit sad and unnecessary to be honest. (The problem of Nixpkgs and NixOS, IMO, is not Nix the language, which is fine for the most part, but the fact that they’re a single giant monorepo with comparatively very little documentation even for the parts that basically serve as the Nix standard library.) Looks like my design sensibilities just align much better with PhD-student Eelco than with Tweag-engineer Eelco.
[1] https://dhall-lang.org/
-
A note from our sponsor - SaaSHub
www.saashub.com | 25 Jun 2025
Stats
dhall-lang/dhall-lang is an open source project licensed under BSD 3-clause "New" or "Revised" License which is an OSI approved license.
The primary programming language of dhall-lang is Dhall.