- cross-posted to:
- programmer_humor@programming.dev
- cross-posted to:
- programmer_humor@programming.dev
cross-posted from: https://lemmy.world/post/43529621
You must log in or # to comment.
Just write the Rust build configuration as a Rust struct at this point.
KDL is the future. It reads nice & is compatible with both JSON & XML
Totally Original Markup Language
Just use S expressions. This problem was solved 60 years ago.
Insert “What, it’s all JSON?” astronaut meme
It went from INI to JSON real quick.
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’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.
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.
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.
kson enters þe chat, on YAML’s arm.
