Everything about TOML format 

Agree. It’s not perfect but easy and good enough. I like it more than yaml, ini or json. It’s less verbose.

I’m fine with toml and other markups but I don’t see how it is better than JSON. They’re all the same. JSON is more clear or more simple but maybe a bit longer. They both end up representing the same data though.

@@theherk JSON isn't what I would call a human readable format, and it's often minified which makes it even worse. Which is better, a single newline or braces around a section with no spaces at all?

@@anon_y_mousse I’m not suggesting there aren’t instances in which one is more readable than the other, but sometimes I think json is more readable. I’ve dealt with some toml files with extended arrays of the same array throughout the file that in json or yaml are all grouped together. That makes logical sense in some cases but not always. And regarding one single line, surely you aren’t suggesting json requires that. One could format a toml file to be more difficult for a human to read than necessary too. But a single line of compacted json is nothing a simple pass through jq can’t fix.

@@theherk I can agree regarding arrays, but then I don't need those in most configuration files. For data, it should just be a binary format to speed up reading and writing. If a user wants to edit data, they should use the appropriate program rather than hand editing with a text editor. As for `jq`, well, not everyone has it installed, especially if any of your users are on Windows they likely won't, and more importantly, they won't know how to use it if they're novices with a command line.

the guy was really a genius

Time for TDSL

You do know that the absence of comments in JSON is meant as a _feature_ ?

Yup, those are different formats, and while I don’t believe TOML is flawless, it has certain features that make it better than JSON for the job its supposed to do.

Variants of JSON like JSONC and HJSON also include ability to comment. I don't think JSON is that great for config file as long it needs to be edited by a human. It's rather clunky to use the moment you go into complex structures. But if it's just simple one level object with few keys then it's a simple solution to a simple problem. Lack of comments still is kind of big negative for config files especially.

JSON is really a pain because of the strict formatting/lack of comments, but what is the "less ambiguity compared to YAML"? I've never found YAML to be ambiguous.

@@CoolerQ no?

JDSL config spec

What to use in 3 (and above) level deep?

@@maxrinehart4177 json or yaml have much better syntax for nested stuff

I prefer the error reporting and structure binding of knuffle as a library to parse kdl, but yeah, it's currently my favorite config format. My main gripe is just that you're not allowed to have a bare symbol argument (eg "foo bar" instead of "foo "bar""), which makes some patterns a bit uglier than they need to be, though I get why.

What are the advantages of toml over yaml? Like you, I'm currently starting out with toml by configuring hugo config files, but I found it very not obvious. Yaml, on the other hand, I understood immediately on the first look (with the knowledge of json).

@@marloelefant7500 i guess for me is that you don't have to worry about whitespace indentation in toml (even though in hugo there are some docs that show whitespace indentation, but i choose to ignore it). also having nested selectors in which for yaml, you'd have so many indented lines to select a specific, deeply-nested key, while in toml, you just put it in dot notation making it shorter and more concise. tbh i don't toally hate yaml in general, as it is one of the morely used configuration specs besides json, and it does have its own advantages, but given the option for usage of toml, i would gladly use it.

Toms a genius!!

Lol, that's a great point, I've searched a bit, when making the vid and its mostly python and rust project configs, as well as some other smaller tools in those ecosystems. On the other hand its a config file format, how many config files do we need anyway

If you self-host a gitlab runner you configure it in a toml file.

​@@orcharddweller I use it in a server for translation of errors, it works like a charm

I think traefik allows toml for config (and more formats). You can also use it for configuring your backend in those cases where your config is a but extensive and complex so that using env vars is not the best solution. I don’t like reading config from files, as you need to make sure to deploy the file, that it is in the path that your app expects it, that you don’t mess up permissions, and more. In rust you can use a macro to read a file’s content AT COMPILE TIME. And you can also do config validation at compile time. That way you can compile it in your machine or CI/CD and just deploy a single binary that will have a embedded, validated config ready to use. You can upload to git config files containing secrets using git secret which will encrypt them, so there’s no security problem in tracking them. Also, you have a history of how config and secrets changed overtime and you can see what’s the current config and compare it to the config used in the last deploy.

a bunch of minecraft mods use toml

Its tricky, because in most cases you want to preserve the original style and comments. Poetry for example uses tomlkit, you can check out their approach here: github.com/sdispater/tomlkit In general, I’d probably avoid writing with TOML it unless you really need it.

Still way better than it used to be when everyone invented their own thinking parsing was a trivial thing.

I think you meant YAML, JSONs parser is much simpler than TOMLs, especially for writing.

@@orcharddweller Even though YAML is indeed the worse of them all, it's indeed much easier to implement a TOML parser from scratch than a JSON one. Mainly because TOML mostly separates stuff into different lines and has a less complex syntax to parse overall.

@@hrudyplayz Hmm, I've never implement neither of them, so I might be talking out of my ass, but I've done a bit of parsing in my life and just looking at this: www.json.org/json-en.html, the grammar feels much simpler than TOML. Also TOML has inline arrays and inline tables, which are in essence a limited version of JSON. So for parsing TOML you need to be able to parse a lobotomized version of JSON, but that's not necessary the other way.

A toml parser comes included with Python 3.11

Neither json nor TOML care about indentation.

That said, that one standardized text format is an XML transformation, if you plan for a text-first use case like a configuration file you might as well use XML directly. The most common "text" form of ASN.1 that users encounter regularly is probably Base64-encoded BER.

@@D0Samp While XML certainly is an encodin scheme for ASN.1 defined data, I was thinking of the possibility of representing example data in ASN.1 itself. It is possible to do so, iirc. (In practice, nobody would want to do so of course, as then you'd need an ASN.1 compiler to parse configuration files.)

I think a guy called Charles Goldfarb did so 50+ years ago, in 1969. Called GML, it evolved into SGML which was standardised as ISO 8879 in 1986! And then of course there is also S-expressions, which is ten years older and simpler. But why use them when we can invent new buggy ones every other year?

honestly, why is it bad? Everything about it is really intuitive except maybe the last part of the video

​@@LukasCobblerxD well, toml is mostly ok. but i do have 2 problems with it: 1. the thing i really dislike about toml is headers vs inline tables/lists -- it is quite ambiguous. btw, yaml has exactly the same problem, only x2 because of additional features. 2. this one is much less severe, but it certainly can bit you in some cases. toml has too many data types. i'm not a hardcore optimization fan, but this is a bit much features for a "minimal config format". personally, i would do only ints, floats and strings, certainly no dates/times etc. instead they could have had an optional type annotation for a string literal, so that user would later parse it properly. with this you would have something like `my_date = @iso_date"2024-01-23"`, which is very explicit, yet minimal. although, i'd say even this is an overkill.

​@@LukasCobblerxD if i had to implement a "minimal configuration language" i would probably start with something like lisp sexprs, but with string literals only, and then add ints + floats and transpose parentheses. so initially it would look something like: ``` message { chat_id { 12345 } user { John Doe } date { 2024-01-20 10:45 GMT+2 } text { "Hello, world" } status { 0 } } ``` of course, one needs a lot of testing and feedback from diverse user group to make a really good format.

@@Daniel_Zhu_a6f If I had to implement a "minimal configuration language" I would probably start with something like lisp sexprs. And then stop right there.

good job tho

YAML is just overcomplicated. Multiple ways to do the same thing and nothing communicates what it does and whitespace management is a nightmare. I don't think you can find anything worse in all honesty. --- # lol - foo: &bar something: is something foo: *bar easy: !!str format to: !!!str read | or is it? think: > is this valid YAML file? Spoiler: it's not, it has valid structure but it won't validate because of whitespace. Spot the error, good luck. Do you know what is defined here? who: | knows: really could or could not be

​@@ShadowManceriI feel like using a subset of YAML just circumvents its feature-creep and fixes some ridiculous design bugs (like the "norway problem"). For instance, you could enforce consistent indentation, force strings to be written either in doube-quotes for single line strings or multiline blocks for multi-line strings and nothing else, drop many useless features (such as anchors, though I kinda like them), drop JSON syntax compatibility, force booleans to use either the "true" or "false" token, etc… Sure YAML is bloated, but TOML gets basically unreadable and unmanagable as soon as you have some levels of nesting. It forces you to repeat many keys (when YAML prevents such repetitions by design). TOML has many more indirections by default than just a YAML document written in a consistent way without the "bad parts". TOML is just another instance of someone reinventing a whole new language that has just as many flaws as the previous one and to fix completely non-existing issues. I mean YAML was mostly fine, you just had to fix the bad parts.

The Norway problem doesn't exist in a decently up to date yaml parser. They added "schemas" to define the interpretations of values and changed the default to be some simple, obvious rules like only true and false for booleans. You can still hit issues with dates with the default schemas if you don't expect them, but there's JSON and core schemas to be even simpler, and compat for earlier yaml compat. It's no longer my favorite format (that's currently kdl), but it's actually hard to point at a specific, actual problem with it now rather than "complexity" or "I don't like significant indent"

@@SimonBuchanNz any YAML compliant implementation is affected by the norway problem. If it is not affected, then you're just talking about a different language, or a subset of YAML. AFAIK, most popular YAML parsers in pretty much every language I've used implement most of the YAML spec (including "NO" to false coercion) and not a strict subset of it. Having 10 different ways of declaring a simple object like a boolean was one of the many things YAML got wrong. And yeah, they added new features to an already bloated data language in order to circumvent mistakes they made in previous versions of the spec.

@@Madinko12 any yaml 1.2 complaint implementation that doesn't default to the compatibility schema absolutely does not parse "no" as "Norway". This isn't a "subset of yaml" thing, it's actual yaml.