DEV Community

Discussion on: Stop Using YAML

rprije profile image
rprije • Edited on

YAML is indeed irregular and hard to consistently parse.

It also suffers from the same problems most configuration languages have: in particular it's repetitive and non programmable. This often leads to writing config generators which in turn introduce generation failures

I think Dhall gets all of this right. Its syntax is regular. It's programmable, but not total. It can't error out or loop infinitely giving it all the reliability of a static config file without the repetitiveness.

jessekphillips profile image
Jesse Phillips Author

That reminds me of Lua. It isn't turning complete but if it has functions I am curious how serialization works with that.

As a write only config I'd recommend Lua.

rprije profile image
rprije • Edited on

I've never used Lua. But I get the impression the goals are a bit different in that Lua aims to be a programming language for embedding into an application and providing a scripting interface for it. As such I think it's probably a bit heavyweight for a simple configuration language. I expect that using it as a configuration language introduces the same problems that config generation introduces in that it can crash or hang which are usually not properties desirable for a configuration language. But, being an embedded language, it does at least mean your application can load it directly instead of config generation needing to be an intermediate step.

This table summarises what I think are some desirable traits in a configuration language, and how well various languages support them:

Language Feature Binary INI JSON YAML Lua Dhall Config Gen
Human Readable No Yes Yes Yes Yes Yes Yes
Regular. Simple Parse Rules No Yes Yes No Yes Yes Yes
Variable Bindings No No No Sort of (anchors) Yes Yes Yes
Imports No No No No Yes Yes Yes
Functions No No No No Yes Yes Yes
Never Crashes (when well-formed) Yes Yes Yes Yes No Yes No
Never Hangs (when well-formed) Yes Yes Yes Yes No Yes No
Readily Readable by multiple Languages No Yes Yes Yes Yes Getting There Yes
Directly readable by the application Yes Yes Yes Yes Yes Yes No
Validation Support No No Yes (Schema) Yes (Schema) No Yes (strong, static types) No
Thread Thread
jessekphillips profile image
Jesse Phillips Author • Edited on

Agreed. Lua has many problems as pure configuration. But it does have ancestry influence to be a configuration language.

I guess I just think there could have been some work on perfecting what was doing, like a limited subset LSTN (Lua Simple Table Notation).

BTW, I hate Lua as a language.

arnauldvm profile image
Arnauld Van Muysewinkel

Any parser implementing the specification will consistently parse. What kind of inconsistencies are you talking about?

rprije profile image
rprije • Edited on

This link summarises some of them:

The problem is the language specification is poorly defined and full of irregularity and corner cases leading to inconsistent parsers.

Much of the problem comes from YAML allowing unquoted strings giving them nothing to clearly distinguish them from other data types. This leaves parsers in the awkward situation of needing to decide through complicated rules whether a token is a string or something else.