I never bothered to read the full spec, so this is a great overview. I like some features that it provides above INI, and it's definitely better than JSON, but arrayed sections are awful. Although, I'd still use it if I need a config file format, because it's only slightly more complex than INI.
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.
I see several reactions where people prefer JSON over this, but there are things that JSON doesn't do that TOML does that are important for configuration files. The most important one being commenting. All features are superior over JSON for readability, you can make your files readable, and less ambiguity compared to YAML. I think it's mostly very important to understand where it's useful and where it isn't.
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.
cool cool, I basically implemented the same thing once, calling it "xini" but concept was very much the same, so guess it is obvious after all biggest difference is the [[notation]] for arrays, which I like quite a lot. I just treated all sections as arrays, which is quite a bit more ambigious
i've learned toml when configuring hugo config files. after learning more about it, i love it more than yaml, and somehow learned a bit of ini. thank you tom for making this
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.
I enjoy toml as a configuration format for tools. Seen some where that it was only even meant to be machine readable and not machine writable like json. I spend alot of time in k8s using yaml and in that world toml would be a bad choice. But i still use it for tooling, where i thin it shines.
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.
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
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.
toml is super easy, my only experience with it was like on cargo project and now i'm developing a project that involves parsing it with the tomlc99 library (the project is frogmake, it's still in early development and i'm working on it every day)
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.
There's a lot I like about TOML, but its sections are not very intutive. I've designed my own format (kesh-lang/na). Still haven't made a compiler for it though. But you're welcome to have a look if you're interested in data notation formats.
TOML is very good, i don't understand a lot of the comments. I'll take TOML over JSON any day. For once, JSON is much harder to read, heavier to write and parse, and pretty much requires an external library due to how complex it is to create a parser of...
@@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.
Coming from python, were indentation is a must, I don't really like the toml structure, I find JSON more readable because there you have indentation plus I don't need to install an additional dependency just to parse the toml into variables 😅
It is more close to INI, it would be better not call as '-ML' even it is an acronym of 'minimal language' Anyway it is further from the actual language.
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.)
When Go 1.20 was out, a lot of CI/CD pipelines broke, because the YAML parser interpreted the 1.20 as a number (so: 1.2 instead of 1.20). To avoid this, you had to write "1.20". YAML was blamed for this. I refuted this, pointing to the parser instead. When I used a YAML parser in Go, I got the string value 1.20 instead of a numerical one. Now I tried this with your TOML Visualizer. Same result. "1.20" is interpreted as string. 1.20 as number. YAML isn't worse than TOML. In fact, I'd rather read YAML since it's more natural for me to write it.
toml doesn't need to exist. first of all, who tf is tom? and how is his language "obvious?" granted yaml isn't obvious but it's more sensible than toml. it also does pretty much anything that you might want. sure the yaml spec is huge but you don't have to implement the whole spec if you don't need to. json is also ok for simple things and is about as obvious as can be. you only need to look at an example json file to pretty much figure out how it works. anything more complicated than passing data around or dead-simple configuration though and json falls flat on its face, but that's what we have yaml for. now this tom guy decides to throw his goofy format into the mix and we have one more silly config language that we have to know.
God I hate toml, using arrays/inner keys in it is absolutely terrible, and it doesn't support a lot of character escape sequences. If there's ever a way to get me to avoid updating a config file at all costs, make it in toml.
as they say, it's bad, but it's the best we have. somehow, nobody tried to think for a bit, when they were inventing text file formats, so .csv, .json, .yaml, .ini, .xml are all uniquely bad in many respects. if only half the ingenuity that is regularly applied to binary file formats was once applied to a text format, nobody in 10 years would probably remember what a .csv or an xml is.
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?
@@LukasCobbler 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.
@@LukasCobbler 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.
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.
Lol "more readable than EVEN yaml" Dude speaks like yaml is most readable format! Yaml is one of least readable formats ever. In fact, less readable only binary serialisation!
Toml is like the love child of ini and yaml
Toml is like ini with types and objects. Literally ini++
Aside from array tables, I love everything about this
I never bothered to read the full spec, so this is a great overview. I like some features that it provides above INI, and it's definitely better than JSON, but arrayed sections are awful. Although, I'd still use it if I need a config file format, because it's only slightly more complex than INI.
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.
I see several reactions where people prefer JSON over this, but there are things that JSON doesn't do that TOML does that are important for configuration files. The most important one being commenting. All features are superior over JSON for readability, you can make your files readable, and less ambiguity compared to YAML. I think it's mostly very important to understand where it's useful and where it isn't.
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?
Gotta love Tom the Genious
the guy was really a genius
Time for TDSL
cool cool, I basically implemented the same thing once, calling it "xini" but concept was very much the same, so guess it is obvious after all
biggest difference is the [[notation]] for arrays, which I like quite a lot. I just treated all sections as arrays, which is quite a bit more ambigious
TOML is great in place of JSON that goes at most 2 levels deep. best format for configurations file, that's for sure.
What to use in 3 (and above) level deep?
@@maxrinehart4177 json or yaml have much better syntax for nested stuff
Tom's a genius
JDSL config spec
You just got a new sub!
Simple and objective explanation!
Very underrated video! Thanks so much!
Very good visualisation and explanation of dotted keys. Personally I find a bit more pace the right thing 😊
I've always been too lazy to read the specification, this video was fantastic.
This is really good!
learned something new today, thank you :)
i've learned toml when configuring hugo config files. after learning more about it, i love it more than yaml, and somehow learned a bit of ini. thank you tom for making this
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!!
I enjoy toml as a configuration format for tools. Seen some where that it was only even meant to be machine readable and not machine writable like json. I spend alot of time in k8s using yaml and in that world toml would be a bad choice. But i still use it for tooling, where i thin it shines.
I use the KDL (cuddle) format in my code now. Rust has a serde extension for it.
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.
Tom is a genious
trying to find any other use of toml beside of cargo.toml
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
this video made me really like TOML!
Nice!
toml is super easy, my only experience with it was like on cargo project and now i'm developing a project that involves parsing it with the tomlc99 library (the project is frogmake, it's still in early development and i'm working on it every day)
Nice and entertaining video, thanks
you lost me at array tables, not gonna lie xd
amazing quickstart video btw
What is common solution for stringification, since "there are different ways to represent the same data" ?
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.
There's a lot I like about TOML, but its sections are not very intutive. I've designed my own format (kesh-lang/na). Still haven't made a compiler for it though. But you're welcome to have a look if you're interested in data notation formats.
❤
TOML is very good, i don't understand a lot of the comments. I'll take TOML over JSON any day. For once, JSON is much harder to read, heavier to write and parse, and pretty much requires an external library due to how complex it is to create a parser of...
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.
4:50 if you meant to use regex for bare keys you shoild escape the last hyphen with a backslash
awesome
Thanks!
We have too many config languages at this point
Still way better than it used to be when everyone invented their own thinking parsing was a trivial thing.
good one
5:20 You can write "please don't" all you want, but all I see is a convenient form to convert my Java property files into.
Coming from python, were indentation is a must, I don't really like the toml structure, I find JSON more readable because there you have indentation plus I don't need to install an additional dependency just to parse the toml into variables 😅
A toml parser comes included with Python 3.11
Neither json nor TOML care about indentation.
It is more close to INI, it would be better not call as '-ML' even it is an acronym of 'minimal language'
Anyway it is further from the actual language.
But why?
Just use ASN.1 - it's a standard, flexible, supports a text format, as well as several binary encodings.
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.)
Jason always seemed like the love child of a data structure and LISP - hard to read and too many keystrokes.
Array tables are cursed ...
Great explanation!
Off topic: the stress syllable of integer is the first: ínteger
When Go 1.20 was out, a lot of CI/CD pipelines broke, because the YAML parser interpreted the 1.20 as a number (so: 1.2 instead of 1.20).
To avoid this, you had to write "1.20".
YAML was blamed for this. I refuted this, pointing to the parser instead. When I used a YAML parser in Go, I got the string value 1.20 instead of a numerical one.
Now I tried this with your TOML Visualizer. Same result. "1.20" is interpreted as string. 1.20 as number. YAML isn't worse than TOML. In fact, I'd rather read YAML since it's more natural for me to write it.
toml doesn't need to exist. first of all, who tf is tom? and how is his language "obvious?" granted yaml isn't obvious but it's more sensible than toml. it also does pretty much anything that you might want. sure the yaml spec is huge but you don't have to implement the whole spec if you don't need to. json is also ok for simple things and is about as obvious as can be. you only need to look at an example json file to pretty much figure out how it works. anything more complicated than passing data around or dead-simple configuration though and json falls flat on its face, but that's what we have yaml for. now this tom guy decides to throw his goofy format into the mix and we have one more silly config language that we have to know.
So Toml is like JSON but with non obvious hierarchy and Python vibes.
"much more readable than json" lmao. Yeah not with that last part, definitely not.
God I hate toml, using arrays/inner keys in it is absolutely terrible, and it doesn't support a lot of character escape sequences. If there's ever a way to get me to avoid updating a config file at all costs, make it in toml.
I knew toml was bud but I didn't think it was this bad
thanks, i hate it!
good job tho
as they say, it's bad, but it's the best we have. somehow, nobody tried to think for a bit, when they were inventing text file formats, so .csv, .json, .yaml, .ini, .xml are all uniquely bad in many respects. if only half the ingenuity that is regularly applied to binary file formats was once applied to a text format, nobody in 10 years would probably remember what a .csv or an xml is.
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
@@LukasCobbler 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.
@@LukasCobbler 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.
Looks much less natural than yaml, especiales arrays of headers
toml is just. shitty json without the outer brackets and quotations around keys
alright thats cool and all but I'm still using json
This is basically systemd .conf files, but more complicated and python-centric.
YAML is just way better
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.
I think this format is unnecessary and JSON hierarchy is much more intuitive. It only looks prettier.
Good tutorial. But I hate what I see 🤢🤮
very bad
Watch at 1.25x speed
Give me yaml any day
Lol "more readable than EVEN yaml"
Dude speaks like yaml is most readable format! Yaml is one of least readable formats ever. In fact, less readable only binary serialisation!
Tom's language isn't all that obvious or minimal. JSON ❤