Dhall-lang Alternatives

dhall-lang reviews and mentions

• I no longer have an old-school cert on my HTTPS site
  18 projects | news.ycombinator.com | 23 May 2025

  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.
  1 project | news.ycombinator.com | 10 May 2025
• Any program can be a GitHub Actions shell
  6 projects | news.ycombinator.com | 7 Apr 2025

  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
  1 project | news.ycombinator.com | 7 Mar 2025
  1 project | news.ycombinator.com | 5 Sep 2024
• StrictYAML
  5 projects | news.ycombinator.com | 7 Mar 2025

  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
  12 projects | news.ycombinator.com | 8 Jan 2025

  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
  16 projects | news.ycombinator.com | 2 Dec 2024

  > 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
  12 projects | dev.to | 2 Nov 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
  3 projects | news.ycombinator.com | 7 Sep 2024

  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

  SaaSHub helps you find the best software and product alternatives Learn more →