Take a leaf out of Rust's book and use something simple and sane like TOML, YAML is a mess.
See: https://github.com/cblp/yaml-sucks
Otherwise this looks like a great project, please don't ruin it with YAML.
There are no good configuration languages in existence and there never will be. We have rejected Lisp/sexp so now we must suffer endlessly.
JSON is close to sexps, but it sucks when comments are not allowed.
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)
JSON5 is probably the best option at the moment.
* 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.
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.
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!!”
[1] https://github.com/cuelang/cue/tree/master/doc/tutorial/basi...
That definitely seems like a solvable problem though.
This is absolutely true. Another recent high profile example I can think of is HCL with terraform.
> YAML though is always a bad fit. If you want machine readable config, use JSON; human readable, use TOML. When does YAML ever fit?
If replacing JSON is the objective, I'd very much rather recommend HJSON [1] than TOML.
But there is also JSON5, among the most popular alternatives. Then HOCON you mention, and probably a myriad more.
This is just plain wrong. It supports exactly the same kind of nesting as JSON.
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.
e: And, AFAIK, I believe the latest YAML 1.2 spec (from 2009) has addressed these issues.
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.
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?
It's a language that coerces basic strings...
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.
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.
> 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.
>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?
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.
So much debate could have been avoided if we stuck with S-Expressions from the beginning.
Was hopeful this would leverage TOML as it's built using rust.