Four weeks ago, I announced Confetti on this blog. Two weeks ago, I shared the project on Reddit and Hacker News to gather feedback. Today, with the release of Confetti 1.0 beta, I’d like to reflect on what I’ve learned, the feedback I received, and where the project goes from here.

Initial Reception#

The initial feedback on Reddit was largely positive. Responses came in quickly and continued for several days.

Hacker News, however, was silent: no comments, no votes, nothing. I figured maybe I posted at an off time or there just wasn’t interest. But — a few days later — I woke up to find my post on the front page!

It turns out Hacker News has a second-chance pool where moderators can manually boost promising projects that did not receive enough initial attention. I have no insight into this process or who the moderator was who surfaced Confetti, but if you’re reading this: thank you.

Since sharing the project on social media, Confetti’s GitHub repository has seen a surprising amount of traffic, suggesting ongoing interest.

Comparisons with JSON#

Several users compared Confetti to JSON. The comparison mainly revolved around typing: JSON has it, Confetti doesn’t.

JSON offers five built-in types: booleans, numbers, strings, arrays, and objects — plus the special value null. Confetti, by contrast, is typeless: it operates using strings and directives.

Types vs Typeless#

I find the comparison with JSON interesting because, in practice, JSON’s typing doesn’t do as much as often implied:

Firstly, JSON lacks a schema language. Schema validation is the responsibility of the user application. Whether you expect an array, object, or a particular element type, you still have to validate it manually — just as you would with Confetti.

Secondly, when validating strings, you sometimes need to go further. For example, checking if a string is a valid ISO 8601 or RFC 3339 timestamp requires manual validation — just as it would with Confetti.

Lastly, when dealing with numbers, checking if a value is a number in Confetti is as easy as comparing it against a simple regular expression. And for booleans and null, these are just strings — “true”, “false”, and “null” — and can be verified with a simple string comparison.

So, in my view, JSON’s minimal typing doesn’t add much in real-world use cases. If you are looking for real, schema-enforced types, then you might consider languages like Pkl that support user-defined types and structural validation.

Feature Suggestions#

Alongside the initial feedback, I received some thoughtful feature suggestions. Here are a few that stood out:

Bracket Syntax#

One suggestion was to use brackets to denote multi-line directives.

Right now, you’d use a trailing backslash:

foo bar \
  baz qux

The proposed alternative uses brackets:

foo [bar
  baz qux]

I found this suggestion interesting because the syntax resembles an array (minus the commas) as written in various programming languages. It might even feel more intuitive for long directives that represent list-like concepts. However, as interesting as the suggestion is, subdirectives can also be used to represent list-likes:

foo { bar
  baz qux }

Here, an application would treat the subdirectives and their arguments as entries in the “list”. So, while the “array”-like syntax is interesting, I don’t feel the need to implement it.

Execution Model#

Another suggestion was to give Confetti an execution model — essentially turning it into a programming language. While intriguing, this is beyond the scope of what I intended for the language.

Confetti is, and will remain, a configuration language. Its syntax is flexible enough to support domain-specific languages (as shown on the examples page), but embedding an execution model would go beyond its design goals.

Discovering Prior Art#

On the Confetti homepage, I compared Confetti to well-known configuration and data-interchange formats like XML, JSON, INI, and TOML. After launching, several users pointed out other configuration languages that resemble Confetti syntax. I’ll briefly discuss them:

SDLang#

Simple Declarative Language, or SDLang, has some syntactic overlap with Confetti, but goes further than Confetti by adding types for strings, numbers, boolean and null, data/time formats, and binary data. While they might share some syntactic similarity, SDLang is clearly closer to JSON or TOML than it is to Confetti.

KDL#

KDL also has a surface-level similarity with Confetti, but again, it supports types and even allows type annotations. It, too, is closer to JSON or TOML.

Tcl#

Tcl is a dynamic programming language with a syntax that vaguely resembles Confetti. However, it’s a full-fledged language with dynamic typing and an execution model. If you like Confetti but need built-in types and evaluation, Tcl — or Lua — might be worth exploring.

Tentative Plans#

As of this writing, Confetti is “done.” Both the C implementation and the specification are in 1.0 beta status.

My plan is to let the language “bake” in real-world usage for a while. Depending on how things go, I might increment the version to 1.0 release candidate in the coming weeks or months, and eventually tag a stable 1.0.

Language Ports#

The current, canonical implementation of Confetti is implemented in C11. I originally intended to write a Python and Go port of Confetti, but I don’t personally have a need for them right now. Authoring them would be mostly for the benefit of others.

With that said, the specification is complete and simple enough that anyone could write a port fairly easily. If you do, I’d love to hear about it!

Closing Thoughts#

The positive reception to Confetti has exceeded what I imagined. I’ll continue to support Confetti for the foreseeable future. If you find bugs in the specification or implementation, please report them on the project’s issue tracker.