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.
“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?
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.
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.
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:
> 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
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 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.
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.
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:
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.
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?
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.
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.
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.
> 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.
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.
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.
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.
>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?
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.
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.
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.