Not-so-fun fact: if you’re transferring a yaml or toml file and the transfer is incomplete, the receiving app may not even know! Yaml and toml both have a good chance of being apparently valid when cut off randomly. This doesn’t impact JSON because of the enclosing {} or [].
Counterpoints:
- TOML is intended for configuration, not for data serialization, so you shouldn’t be sending it over the wire in all too crazy ways anyways.
- Most protocols will have a built-in way of knowing when the whole content has been transferred, typically by putting a content length into the header.
- Having to wait until the closing
}or]can also be a disadvantage of JSON, since you cannot stream it, i.e. start processing the fields/elements before the whole thing has arrived. (You probably still don’t want to use TOML for that, though. JSONL, CSV or such are a better idea.)
I’m only being pedantic. Toml is not bad. Yaml I personally don’t like because I don’t approve of semantically required whitespace but I know I’m in the minority there.
- It’s not the norm in smaller companies, but big companies can use config servers where an app will retrieve its config on startup over the network. To be fair, I think they fall back to a platform specific encoding though.
- Better hope it’s built in. I don’t remember the last time I verified a Content-Length was accurate. Also this generally applies to networking; disk writes don’t get this same verification especially if a process is killed mid-write.
- True point, no real notes. I’ve recently been dealing with streaming JSON for AI, it’s SOO verbose for the few tokens that come across in each message. I don’t know how gRPC wasn’t chosen, or at least made an option, but oh well.
You make good, valid points and I know I’m talking about edge cases that require the stars to align to break. It reminds me of an old, not-quite-relevant-but-oh-well saying “a ‘one in a million’ chance at 1GHz happens every millisecond.” The law of large numbers isn’t always on our side.
Whitespace being part of semantics is always a bad design decision. You’re not alone in this. I wish this was more widely accepted. But alas, it’s not. For a configuration language I can accept it a bit more. But for a programming language it’s a big faux pas in my opinion (looking at you python).
I was in the same camp when I had to use Python on the job, but when Scala introduced (optional) significant whitespace, I actually grew to like it a lot. I think the important difference to Python is, that with a good type system and compile time checks a whitespace error is basically always a compile time error in Scala. That’s also for me it’s worse in a configuration language (unless you have a schema file for validation, which is rarely the case sadly)
deleted by creator
Insert “What, it’s all JSON?” astronaut meme
I’ve never gotten to be good friends with
toml. I’ve never liked that the properties of some thing can be defined all over the place, and I’ve definitely never liked that it’s so hard to read nested properties.JSONis my friend.They serve largely different use-cases. JSON is good for serializing data. TOML is good for configuration.
.vscodewould like a word.But besides that, I just can’t understand why even someone that hates
JSONwould chooseTOMLoverYAMLfor a config file.Most of production failures in my company in last few years come from people making mistakes in yaml indentation.
To me, that makes it sound like you’re writing too much and too complex yaml files manually, and/or that you don’t have good enough CI to catch invalid configurations. Unless, of course, you have very few prod failures overall, and the few that happen are due to yaml indentation, which I still think is a bit weird, since an invalid config caused by incorrect indentation should ideally be caught at compile time (if you’re generating code from the yaml) or by some linter or something (if you’re using it for config).
In yaml a mistake in indentation can easily result in a business error without config becoming invalid.
Writing too much complex configs in files is a problem too ofc, we ended up moving a lot of stuff like that to a DB lately.
I’m not a fan of indentation being logically meaningful not just in yaml. If you mess up indentation in python you can also get a technically valid code that’s wrong logically.
VSCode is Electron, i.e. a webpage, so it’s not hugely surprising that they opted for the natively supported JavaScript Object Notation.
And also shows that they don’t care for using the right tool for the job to begin with.Personally, I much prefer TOML over YAML, because it does not have significant whitespace, and because you can read the spec in a reasonable amount of time. It just has so much less complexity, while still covering the vast majority of use-cases perfectly well.
I’ll agree that significant whitespace can be a PITA (one of the reasons I prefer json over yaml), but at the same time I think improper or lacking indentation hurts readability even more than significant whitespace. Toml basically encourages a completely flat structure, where objects and sub-objects are defined all over the place. At that point, I much prefer an enforced structure with whitespace.
I can understand the sentiment and would 100% agree for programming languages.
But personally I actually like that it encourages a flat structure, because you do not want to be yakshaving the structure of your config file. Too much nesting means you will sooner or later run into configuration keys being nested under the wrong category, because your project context changed over time.And well, as I’ve argued in a few other comments already, I think non-techie users have a disproportionally simpler time when no nesting is used. They understand the concept of a heading and then just adding a line underneath the appropriate heading is really intuitive.
You can just tell them to add the linecertificate="/tmp/cert.crt"under[]and they will find a line in their config file which actually reads[]and they can just paste that line as-is.With nesting, they’d need to add it under here:
network: { tls: { certificate: "/tmp/cert.crt" } }Which means:
- You need some awkward explanation where they should nest it, or an explanation that e.g. “network.tls” translates to nesting.
- They will ask whether they should indent the line you sent them.
- Well, and it’s also surprisingly difficult to explain between which braces they should put the text, and that’s at the end of the braces, but not after the braces etc., if you’re talking to them on a call.
It’s not even that I’m completely enamored with TOML, but this aspect is certainly growing on me…
JSON5 or even JSONC are as good as TOML for configuration, if not better.
INI can be nicer for non-techies due to its flat structure. However, TOML seems to be in an awkward spot: either I want flat approachable (I’ll pick INI) or not (I’ll pick JSONC). Why would I want a mix?
Well, you can still decide how much of the TOML features you actually use in your specific application. For example, I’m currently involved in two projects at $DAYJOB where we read TOML configurations and we don’t make use of the inline tables that OP memes about in either of them.
Ultimately, the big advantage of TOML over INI is that it standardizes all kinds of small INI extensions that folks have come up with over the decades. As such, it has a formal specification and in particular only one specification.
You can assume that you can read the same TOML file from two different programming languages, which you cannot just assume for INI.I can’t really decide what extensions my users will face, once they are supported. Therefore too many extensions seems bad to me.
We just document that this is how you write the config file:
[network] bind.host = "127.0.0.1" bind.port = 1234 # etc.And that seems straightforward enough. Yeah, technically users can opt to use inline tables or raw strings or whatever, but they don’t have to.
Configs are often shared, just to explain my reservations with TOML. For my project, I used INI instead.
Just write the Rust build configuration as a Rust struct at this point.
If you want to load at runtime you can use https://docs.rs/ron/latest/ron/. The structs are a weird combination of the two ways to define a struct in rust, making the ron notation of structs invalid rust, but having proper enums makes it worth it.
It went from INI to JSON real quick.
Totally Original Markup Language
KDL is the future. It reads nice & is compatible with both JSON & XML
I love hjson / json5 for config files: https://hjson.github.io/
Never understood the toml philosophy of trying to flatten every object field.
Well, TOML is essentially just an extension of the INI format (which helped its adoption quite a bit, since you could just fork INI parsers for all kinds of programming languages).
And then, yeah, flattening everything is kind of baked into INI, where it arguably made more sense.
Although, I do also feel like non-techies fare better with flat files, since they don’t have to understand where into the structure they have to insert the value. They just need find the right “heading” to put the line under, which is something they’re familiar with.
Just use S expressions. This problem was solved 60 years ago.
kson enters þe chat, on YAML’s arm.
