YAML sucks but so does TOML, especially when it comes to nested data structures like the layout.yaml shown on the front page.

There are no good configuration languages in existence and there never will be. We have rejected Lisp/sexp so now we must suffer endlessly.

I think JSON would be perfect if it a) allowed comments, and b) had multi-line strings.

It has exactly five data types, each with very clear and distinct notation that nests consistently (the top level isn't somehow "special" and there's no messing with significant whitespace). Only two collection types: keyed, and unkeyed. In some sense it feels like the apotheosis of untyped data-modeling.

a) reminds me so much of this classic

https://thedailywtf.com/articles/the-inner-json-effect

“Tell us what you did to JDSL,” one of the VP’s asked.

“I don’t think I did anything,” Jake answered. “I’ve only been here two weeks, trying to learn JDSL and how the customer portal works. I don’t even know how to deploy it!”

“You made a few commits to Subversion!” Tom shouted.

“Well, yes. I added a few code comments, trying to–”

“You can’t use comments in JDSL!” Tom shouted. “THAT’S WHAT BROKE IT!!”

That 100% has to be fake. I NEED it to be fake. Are there production systems that work like this? Du they have one "rockstar" developer who does stuff like this?

Most of TDWTF is a kernel of truth surrounded by about three pages of fiction.

I just wish JSON had fixed decimal numbers, a timestamp type, and a binary blob type :/

I agree that TOML sucks for nested structures.

JSON5 is probably the best option at the moment.

https://json5.org/

* Instantly obvious what the structure is (unlike YAML or TOML).

* Everyone knows JSON already. This just makes it a bit nicer.

* No noob security mistakes or type confusion caused by underquoting like YAML.

Don't forget the truncation problem with YAML/TOML. A partially read/transmitted YAML/TOML file is often still considered valid.

That also makes it really easy to concatenate them, either `cp a.yaml + b.yaml c.yaml` or just `cat a.yaml >> b.yaml` - which is quite nice, compared to trying to do this with JSON etc... files.

I would say that Dhall is fine, just from a parallel universe.

JSON is close to sexps, but it sucks when comments are not allowed.

Which is why EDN is so much better for config.

Have you looked at Cuelang [1] as a configuration language or source of truth?. It's still new but it's a superset of JSON but attempted to combine data/schema into one and reject inheritance and replace with validation instead.

[1] https://github.com/cuelang/cue/tree/master/doc/tutorial/basi...

Take a look at HOCON (Human-Optimized Config Object Notation)

https://github.com/lightbend/config/blob/main/HOCON.md

Yes! I logged in just to mention HOCON, then I noticed you have mentioned it already :- )

So, the project you linked to is Java / Scala: https://github.com/lightbend/config

And there're also (basic? complete?) HOCON parsers in Javascript and Rust — I investigated this a while ago, because I want to use HOCON everywhere in my projects:

https://docs.rs/hocon/0.5.1/hocon/ (Rust)

https://www.google.com/search?q=hocon+javascript (Js, a few different)

The Rust version:

> This implementation goal is to be as permissive as possible, returning a valid document with all errors wrapped in `Hocon::BadValue` when a correct value cannot be computed

How nice :- ) (it seems to me)

I agree about sexps, it feels like the right default for storing human readable data. The only place where I think it's a little weak is when used more like markup, since data would need to be in quoted strings.

That definitely seems like a solvable problem though.

Or, to avoid sooner or later falling into Greenspun's Tenth Rule, just go immediately to Lua, which actually evolved out of a configuration language (https://www.lua.org/history.html), so it has syntax & features that are quite friendly for writing configs.

I'd never heard of Greenspun's tenth but that's good to know! I had a personal theory that all program configuration interfaces eventually become programming languages (poorly) and maybe this fits in there.

> I had a personal theory that all program configuration interfaces eventually become programming languages (poorly) and maybe this fits in there.

This is absolutely true. Another recent high profile example I can think of is HCL with terraform.

I actually just stumbled upon an article where someone went through HCL and finally landed at Lua: http://dnaeon.github.io/choosing-lua-as-the-ddl-and-config-l...

Lua tables are great for nested configurations like layouts.

> It's fashionable to hate XML because it was used in a lot of places it was a bad fit in the 00s, but at least it's a pretty good document language.

> YAML though is always a bad fit. If you want machine readable config, use JSON; human readable, use TOML. When does YAML ever fit?

https://twitter.com/carlmjohnson/status/1372224080749993988

I never got this stance; JSON sucks for config files, because as a user, if there is anywhere that I need and am more thankful for comments, is in a configuration file. And TOML is maybe a good substitute for INI formats, but it doesn't really support nested data like JSON would, so suggesting to use TOML instead of JSON is misleading except for the simplest and most basic needs.

If replacing JSON is the objective, I'd very much rather recommend HJSON [1] than TOML.

[1]: https://hjson.github.io/faq.html

What about HOCON? https://github.com/lightbend/config/blob/master/HOCON.md

I guess why not? I mean, there are lots of options here. I prefer HJSON, also it helps a lot that its website does a very good job at convincing other fellow devs to try it...

But there is also JSON5, among the most popular alternatives. Then HOCON you mention, and probably a myriad more.

> it doesn't really support nested data like JSON would

This is just plain wrong. It supports exactly the same kind of nesting as JSON.

Could your problem be partially resolved by having a key called description or comments where you could provide some clarification?

But now that's part of the data and the parser doesn't know any better. Comments are more useful if they are close to the thing being talked about.

The human readable part is a bit subjective. I find YAML more human readable than TOML.

Readable, maybe? I mean as long as the YAML is correctly quoted, sure, it looks fine. But that's a big if. But writeable, hell no. I have been writing YAML for years and still have no idea how the quoting works, and not for lacking of looking it up in the past.

Configuration language seems to be a hot topic at HN today, as every day. "Don't use X, use Y instead" has spawned this thread with everybody putting in their favorite configuration language in the hat for consideration. Lets list the ones that have appeared so far:

YAML, TOML, Lisp, Dhall, JSON, EDN, JSON5, HOCON, Lua, HCL, XML, HJSON, Starlark, strict yaml

About a third of which I'd never heard of. And because I can't help myself (the dogpile is so enticing!), I have to say that the one that I'm most interested in is: Dhall.

You can find absurd behavior during corner cases in nearly any non-trivial language. YAML is a great language when you need to represent objects in something universal and human readable/writable. Not perfect of course, but TOML's limitations can turn stuff into a monstrosity with it's limitations. Ansible inventory files come to mind here.

One can find absurd behavior in corner cases of any non-trivial language, but one can find absurd behavior in YAML without even looking for it.

Such as? All these cases with no and norwegian or whatever but I haven't run into major problems and use it frequently.

e: And, AFAIK, I believe the latest YAML 1.2 spec (from 2009) has addressed these issues.

The "no"/"norwegian" thing is emblematic of very sloppy thinking in YAML's design, and it's far from the only example.

It's possible to avoid these pitfalls - like people do with PHP - but why burden users with that in a new project when better options have been available for years?

They obviously like Rust, why not just follow their lead with TOML?

That "feature" regarding "no" hasn't even been present in the YAML spec since 2009.

Thanks for being clear about this and repeating it. I didn’t know. I think I will only use YAML 1.2 as configuration language.

I use it frequently too, but there's some terrible edge cases: https://stackoverflow.com/questions/53648244/specifying-the-...

? I don't think these are issues with Yaml 1.2, the spec since 2009.

What about `thing: 1.0` and `thing: 1.0.0`?

Parser implementations have also been buggy. The ruby one in particular being a source of RCE's. Of course, these are implementation issues, but surely a simpler specofication would be easier to implement. And the current specification is anything but simple, clocking 84 pages in the PDF flavour.

The NO alone should give you pause...

It's a language that coerces basic strings...

I think the biggest problem with YAML is not YAML itself but what people use it for. It's very flexible and readable for smaller files (much more than TOML - which is awful for hierarchical data).

A bigger problem is that so many things are using config files that should be proper DSLs or libraries, but no one wants to maintain a library (or create RCE as a service by accident) and no one wants to write a parser/interpreter.

Most of the "YAML sucks" issues would go away if we stopped treating LowCode as something desirable (we do actually need to write code sometimes, as it happens) and if we had better sandboxing/parser generators along with less animosity towards DSLs.

My beef with YAML is that configuration should be flat, not hierarchical. There should be at very most one layer of nesting, to facilitate categories. INI files are fine.

People do unholy things with it like nest bash scripts in it that should never be done. Text files should never have more than one syntax needing parsing. It's bad enough, say, embedding SQL into some python. But doing that with YAML is just the worst.

You should be able to use regexes to deal with non-code text files. JSON, YAML, the whole motley crew require parsing. Don't get me started on JSON log files.

There is now a good parser/interpreter already written for a proper configuration DSL in Rust - https://github.com/facebookexperimental/starlark-rust

This feels like a bit of a bikeshed. There are problems with many configuration languages. I don't see anything related to yaml on their issue tracker.

> bikeshedding

> Futile investment of time and energy in discussion of marginal technical issues

I don't see how the choice of configuration file format is a marginal technical issue. It makes a big difference to the ergonomics of a tool.

It's one of the things I like most about Rust over my main programming language Kotlin. Rust has Cargo which uses TOML, which is nice and simple. It's so much more pleasant to use than Koltin's Gradle.

HN on ShowHN posts is almost always a series of bikesheds

If your Rust program needs a more complicated configuration (conditionals, access to APIs and so on), also look at Facebook's Starlark parser and tooling[1]. Starlark is a subset of Python used by Bazel, Buck and a few other projects.

[1]: https://github.com/facebookexperimental/starlark-rust

Non-rhetorical questions: why not use the language itself so people can leverage features like autocomplete, type-checking, linting, and intuitive error handling in an IDE? Is there anything about Rust that makes it impractical for representing config/dependencies/etc?

The point of config/scripting languages is to make the user's life easier. I assume nobody wants to deal with the Rust borrow checker and lifetime annotations while tinkering with their configuration. So it depends - should it be an unchanging set of options/flags the user can switch around and then recompile? Probably fine though it'll never be as quick as e.g. recompiling programs from the suckless project. Want to expose interfaces for users to expand and modify the program's code? Not so much.

Rust is a fantastic language, but it's probably not the kind of language you want for this purpose. Same reason why game engines often have scripting languages; so people don't have to deal with C++ where it's not required for performance.

Imho the best compromise is embedding something like Lua which is simple and still flexible enough to allow more than JSON-style declarations.

That is one thing people love about xmonad, you write your config in haskell.

how do you imagine this working? should the binaries for this ship a rust compiler?

You could, for example, compile AOT to a JSON file and build everything deterministically from there. Tell devs to not edit that JSON directly. I believe NPM and Yarn do something similar.

i have no idea what you're saying

>compile AOT to a JSON file and build everything deterministically from there

you want the dev that develops zellij to AOT compile all settings (that they set using rust as you imagine) to a JSON file that is then... what by end users? inspected but not edited? how would settings change then?

Yep. Rust is a compiled language with monomorphized generics. It's slow to compile, and also you'll need to carry rustc everywhere. rustc is huge.

Or, one could embed Chez Scheme, the compiler of which is like 800 kB in size and compiles stuff very quickly.

Or, one could embed Lua, which has simple syntax and built for that exact purpose

Possibly, but the dilemma of having to choose between Lua 5.4, with its portability and language features, and LuaJIT's performance isn't very pleasant. I'm sure that LuaJIT updated to 5.4 version language would be very popular, but it doesn't exist right now.

Another option is JSON with the "$schema": "..." item[0]. Most editors seem to pick that up automatically and provide autocomplete and type-checking.

[0] https://json-schema.org/

YAML is the worst, kill it with fire. Whether TOML is decent alternative is debatable though, i'd prefer EDN.

I feel like I read almost the exact same comment after the honeymoon of every new file format used for configuration.

EDN is not new. Just not familiar to enough people. It’s incredibly powerful and ticks all the right boxes.

If you don't like it, just generate the YAML from something else: https://github.com/dbohdan/remarshal

Search up "strict yaml" it is a pretty good alternative to both.

There are a million good alternatives. The question is why would you deliberately choose YAML for a new project when we now have a lot of real world experience about how it sucks. It's like deliberately choosing SOAP for a new API…

I get the yaml hate - I used to do that too. But as I worked more with it I can say I have not had any problems. I think toml feels actually more complex

I think YAML works fine if you're mapping it into typed data structures, because if you know the target type, you can coerce where possible and fail with an error message otherwise. It can potentially cause a mess if you're using it in a dynamic language, and aren't explicitly coercing/validating the input.

For hierarchical data I've found JSON5 to be much more enjoyable to work with than YAML or TOML.

Yes, TOML is great for some things but not hierarchical data.

> You have a problem and you need a configuration language, so you pick YAML. Now you have two problems.

So much debate could have been avoided if we stuck with S-Expressions from the beginning.

One of the most painful things about using tumxp is modifying the YAML to make it useful.

Was hopeful this would leverage TOML as it's built using rust.

same comment, different config format, year after year after year...

i submit dhall as a good alternative

https://dhall-lang.org/

YAML is the worst choice. Please use something else!