More brainstorming for changing the landing page


Who do you view as the target audience, Gabriel?

I remember that this was an important aspect when FPComplete made its own Haskell landing page – it was targeted more at the CTOs than at the programmers.


@SiriusStarr: How about: “A safe templating language?”


@Gabriel439 That gets both to type safety and the fact that it’s not Turing complete (and thus safe to import stuff from untrusted websites), so I like it.

Maybe “templating and configuration language” though, since it does more than just templating?

And is dropping the “programmable” good or bad? It should be immediately obvious that it’s programmable, but…


Slightly less static, but could also make it change through multiple lines, like:

“Dhall is…[ ]”

And then what’s in [ ] changes every couple seconds through like:

  • a lifesaver for templating YAML
  • a safe templating language
  • a programmable configuration language
  • the answer
  • like JSON + functions + types + imports
  • pure and functional
  • etc etc

Which would maybe get at the diversity of applications of the language (and at least one of them is probably going to catch your eye).


@sjakobi: The target “buyer” is a technical leader, typically in DevOps or somebody who maintains shared infrastructure. Specifically, somebody who has sufficient credibility within the organization to incorporate Dhall into their team’s or company’s deployment pipeline. This will typically be the person responsible for evaluating new technologies, and doing requirements gathering design for new projects. This person will definitely be technical, possibly an individual contributor or possibly an architect. They will likely be part of an organization of at least 20+ engineers that is noticing significant configuration drift due to repetition. Common problems that this person struggles with are:

  • Making sure that dev/staging/prod share common configuration options
  • Keeping resource specifications (such as CPU/disk/RAM/ports/hosts) synchronized across programs written in multiple languages
  • Reducing boilerplate for each new component that needs to be built so that people don’t just keep adding unrelated functionality into existing components
  • Training junior developers to properly and idiomatically use internal tools instead of copying-and-pasting from examples
  • Keeping the deployment pipeline’s “footprint” as lean as possible so that it is easier to document/maintain/repave


@SiriusStarr: I’m fairly certain that we should not dilute our message. This is something covered in detail by the book Crossing the Chasm, but I can summarize it here.

You want to focus on one narrow area when marketing your “product” because you need to reach a certain critical mass of users to trigger a viral chain reaction where recommendations spread by word of mouth. If you “play the field” then you never reach that necessary critical mass of users necessary to keep that positive feedback loop self-sustaining.


@Gabriel439 Gotcha; you’re the boss. I’m just offering my two cents as someone who only fairly recently discovered Dhall and would never have found it if it were being billed as a YAML templating tool. There may very well be huge demand for just such a thing; not my area of expertise, haha.


@SiriusStarr: So I’ve been trying to think of the right choice of words to not suggest that Dhall can only be used for templating (i.e. it can be a configuration format in its own right). Maybe something simple like:

“Maintainable configuration files”

That makes clear who the target audience is: somebody struggling with configuration files. It also makes clear what the innovation is: maintainability. Maintainability then justifies the choice of language features:

  • Functions - Code is easier to maintain if you don’t repeat yourself
  • Imports - You need a module system for projects that exceed a certain size
  • Types - Types make refactors safe and easy


@Gabriel439 I like that a lot, since it applies to basically every conceivable usecase, whether templating or using Dhall directly. And I would break out those bullet points explicitly like that to spell it out for people.

I suppose dhall text is sort of the one thing left out by this, but that’s a pretty fringe thing (even though it’s what I use the most).


I’ve thrown together some ideas from this thread and the older brainstorming thread in an unstructured way on figma:

This is obviously far from a finished design for a landing page, but it might be nice for coordinating some brainstorming!

Feel free to edit this file, anyone with the link can edit it. There is a git-like history, so even if you mess something up - no problem! (Also, there’s Ctrl+Z :wink: )

Figma could also be used to create a final design for the landing page. Something to show to people to gather feedback before having to implement it tediously using html and css.

I might pick up designing the website as an exercise for myself just for fun. I’ve designed some personal things before and I can believe I can do better than the current design aesthetically, but I’m not a professional designer, so there is a possibility I won’t come up with anything good.


I think the two things that Dhall “is” to most people are:

  • Templating
  • Structure

So saying just “safe templating” seems to miss out on talking about how this is structured templating (not just advanced string interpolation). But saying YAML, while it does convey the structure, also limits peoples minds to thinking about generating YAML files (and maybe not other formats, or better yet, using Dhall directly).


So I think if we change the major “bullet points” to follow the maintainability theme, here are some initial ideas I had while brainstorming:

Don’t repeat yourself

Struggling with configuration drift? Keep your infrastructure in sync by creating a single source of truth that you can reference everywhere.

Highlight the following features: functions, imports, and multiple integrations

Fearlessly refactor

Need to clean up a big mess? Dhall provides built-in support for static types and change control so that you can move fast without breaking things.

Highlight the following features: types, dhall hash (to verify that a change was behavior-preserving), dhall diff (to verify that an intentional change had the expected effect)

Safety first

Sick of Turing-complete configuration languages? Dhall is a total functional programming language that forbids arbitrary side effects, so the language can never fail, hang, crash, leak secrets, or compromise your system.

Highlight here: non-Turing-complete, semantic integrity checks, pre-normalization, CORS, XSS protection, same origin policy


@matheus23: Also, whenever you feel ready to make changes to the website the code for that lives here:


This is really useful for potential website content!

Another thing I was thinking about: We could go with a structure similar to rust’s landing page. They have subpages for different applications rust it is good at. So there is another small subpage for webassembly, command line applications, embedded systems, etc.

My suggestion would be to have a kubernetes sub-page showing off useful projects/dhall features for the kubernetes application especially with a prominent link to it on the main page.

What @singpolyma’s said about a too-narrow dhall description resonates with my gut feeling:

Having two pages keeps dhall open enough on the main page, but anyone interested in using dhall for kubernetes configuration can quickly find a good place to start.


I’ve been looking around various landing pages for programming languages. For anyone who wants to do that as well, here are some noteworthy landing pages:

Looking at these examples, I think we should mention that dhall is purely functional as that might not be obvious to newcomers. Scala, haskell, fsharp and clojure seem to advertise this. (Counter-argument: elm and racket don’t seem to advertise it).


Well, these are general-purpose languages, but Dhall isn’t one. It might be more fruitful to compare it with languages in a similar space like or

EDIT: …or Nix:


@matheus23: Even for general purpose languages, I don’t think pitching in terms of “functional” convinces enough people to switch.

I find that an effective guideline when drafting a pitch is to frame technology choice in terms of how it effects people’s careers (because most mainstream programmers are career-oriented when evaluating which new technologies to invest in).

As a simple example, you might sell Elm to a JavaScript programmer like this:

Do you really want to spend the rest of your career debugging “undefined is not a function”?

… or for Dhall advertising to an Ops person:

Did you really dream of becoming a “YAML engineer”?

The reason why this approach works is that people are more likely to take leaps of faith on new technologies when they evaluate the cost of poor technologies across a larger time span (i.e. their entire career).


Yes. I wouldn’t pitch Dhall as a functional programming language, but I would like it to be mentioned.
(I think) most people already can already get more of an idea about what Dhall is when they hear ‘functional’: They will expect to see things like mapping or folding. To me this is equally as important as “Strong Types”: From this they I expect them to envision something like Optional.

To be clear: I’m not talking about “functional” being a selling point. But I think the webpage shouldn’t only contain selling points, but also simply a description of what Dhall is. I imagine someone coming to a landing page would like to see at least one sentence similar in style to a wikipedia page.

I think the first sentence of Elm’s wikipedia page is amazing:

Elm is a domain-specific programming language for declaratively creating web browser-based graphical user interfaces. Elm is purely functional, and is developed with emphasis on usability, performance, and robustness. It advertises “no runtime exceptions in practice”,[6] made possible by the Elm compiler’s static type checking.

(I couldn’t find a close example to Dhall: jsonnet and cuelang don’t have a wikipedia entry, and I don’t particularly like the first sentence of nix’s entry.)


I think the live demo on accomplishes the goal of showing people what kind of language Dhall is


Alright, I have a pull request up for updating to update it to reflect the new pitch based on maintainability. If you all have some time take a look at it and let me know your thoughts. The pull request has a link to a tarball you can download to try out the website built from that branch.