Idea for a slight rebranding change

#1

Recently I rebranded Dhall to “A non-repetitive alternative to YAML”, but after studying more user feedback I think we can improve the message a bit more.

I’m still hashing out the exact 1-line summary, but my new thinking is that the emphasis should be on configuration management at scale. However, “configuration management” can be easily misunderstood to be something unrelated, so I’m looking for a better way to phrase things.

The first reason I suggest a focus on “scale” is because it concisely highlights and motivates all of Dhall’s key features:

  • Functions: Help reduce repetition that you often get as configurations grow
  • Types: Help reduce defects that you often get as configurations grow
  • Imports: Help break up giant configuration files into modular units
  • Integrations: Provides a single-source of truth across multiple configuration file formats

The other reason I suggest focusing on scale is because I find that this is often the key differentiator between people who continue to use Dhall or abandon it when test-driving the language. People who want a small-scale replacement for YAML typically end up using TOML instead since they don’t need any of Dhall’s features if their configuration file is small. People who stick to Dhall tend to be enterprise deployments dealing with large and sprawling configuration files.

This would also suggest some changes to what the website emphasizes. For example, we wouldn’t really need to emphasize “readability” since that’s not material to how well the configuration file format scales in the large (although it’s still a nice feature).

5 Likes
#2

One of the primary benefits that we get out of Dhall is the ability to generate configuration for multiple products/tooling from the same, base “super-configuration” type. This type is passed as a parameter for each of the Dhall functions which returns the configuration for that part of our toolchain.

For example, Concourse and Kubernetes. Concourse expects its configuration file to appear one way, and Kubernetes expects its objects to appear a different way. By defining those configurations as functions of a common super-configuration type instead, we make the “real” configuration of our entire system into a combination of the super-configuration type, a record of that super-configuration type, plus the functions. This makes sure that our Concourse and Kubernetes configurations (among others…) stay consistent with each other.

I think that stuff like “non-repetition”, “non-Turing-complete”, “scale”, none of this stuff really explains to people the power behind this language. Functions, types, and imports are language features, but not the language’s purpose. They are how I would adopt the language, but not why I would adopt the language (and don’t get me wrong, the How is super-important, and it’s actually the reason why the language is so powerful, but it’s not sufficient as a marketing hook). Dhall does for us in the domain of configuration something akin to what Kubernetes does for containers - it allows us to write configuration at a higher level of abstraction, with a variety of benefits from doing so.

So, to throw ideas at a dartboard, I’d recommend something along the lines of:

  • “write configuration at a higher level of abstraction”
  • “gain control over different configuration formats”
  • “meta-configuration” (yeah, it’s not the configuration of the configuration, it’s not the same thing, I get it, but still)
  • “simplify how you configure all your tooling”
  • “factor out a single source of truth from your configuration”

For what it’s worth, I don’t know how many enterprises are going to use Dhall at this stage? Obviously it’s very relevant and much more powerful when deployed at enterprise scale, but in my experience enterprises tend to be culturally conservative; Dhall as an option in the enterprise won’t be judged by its technical merits but by whether early adopters can survive politically when they put their jobs on the line for having introduced something new. Part of pointing out that Dhall is a higher level of abstraction for configuration is that companies and teams of all sizes use multiple tools chained together, and it helps point out that Dhall is the best choice for audiences which are more likely to be in a position to adopt the language.

7 Likes
#3

@ari-becker: Yeah, what you said really resonates with me. In particular, I like the last 1-line description you suggested, which I’ll slightly rewrite to:

  • “A single source of truth for all program configuration”

Besides explaining the “Why”, your take also succinctly justifies the other features:

  • Imports: Obviously you can’t have a single source of truth if you can’t import anything
  • Integrations: You can’t consolidate everything if you don’t support desired languages/formats
  • Functions: You also need to massage / migrate the data to fit various schemas / versions
  • Types: Changes to a schema-less source of truth can easily break derived configurations
#4

The word that I see most often from people when they first “get” Dhall is “template”.

Typesafe templates for configuration and data

?

More brainstorming for changing the dhall-lang.org landing page
#5

@singpolyma: Ah, I see. So that’s positioning Dhall as an alternative to templating YAML with Jinja (which is horribly unsafe). That’s also consistent with the current branding of Dhall as a better alternative to YAML.

#6

Right, Rails projects are full of *.yaml.erb files which is a terrifying nightmare. Often just so they can read from environment variables, which Dhall can do natively.

1 Like
#7

So I’ve been thinking about this a bit more and decided to stay with the current branding (i.e. saner alternative to YAML).

The reason why basically comes down to the fact that we should only commit to something that we currently support really well.

Dhall as a “single source of truth” is a good thing for us to aspire to, but we’re not yet in a position where we can deliver on the full promise of that due to insufficient language bindings and missing support for some key integrations (like TOML, INI, and XML).

I also have the same concerns for my own suggestion to advertise the use of Dhall at scale. I realized we can’t confidently recommend it for that use case until we’re done with performance optimizations that are still in the pipeline (especially the normalization-by-evaluation work of @AndrasKovacs)

In contrast, Dhall as a YAML replacement is basically already “there”. Once you install the dhall-to-yaml executable you are good to go. There is still a bit more that we can improve here for handling weakly-typed schemas, but it’s still the most fleshed out use case for the language (especially once we release the new toMap keyword and support for the new JSON type).

3 Likes