• glibg10b
        link
        fedilink
        611 months ago

        Some applications don’t have enough config entries to warrant support for nested entries

        Some applications need variable-length data, and some even variable-length lists

        Some applications don’t care about having fast read/write times or a small memory footprint and can do with more complex formats that require the use of third-party libraries

        Some embedded applications (e.g. AVR) don’t have access to a whole lot of libraries

    • Yup. If I have to pick one for a new project, I’ll go with TOML unless there’s a reason to pick something else. I like that it’s simple, while also having a bunch of features for when the project grows.

      • JackbyDev
        link
        fedilink
        English
        511 months ago

        Pretty much same here. With Spring stuff I still use YAML because TOML doesn’t have first class support yet. If TOML is an option I don’t have to go too far out of my way for them I go for it.

        YAML has too many foot guns. It’s still less annoying to read and write than JSON though. Properties files are okay but there doesn’t seem to be an agreed upon spec, so for edge cases it can be confusing.

        • @sugar_in_your_tea@sh.itjust.works
          link
          fedilink
          3
          edit-2
          11 months ago

          Yup, YAML is a terrible data format, but for a configuration format that you completely control, it works well. Your parser only needs to be good enough to read the configs you create.

          Likewise, JSON is a pretty bad config format due to strictness in the syntax (no optional commas, excessive quotes, etc), but it’s pretty good data format because it’s pretty easy to parse.

          TOML is like YAML, but it has fewer corner cases so it’s pretty easy to learn completely.

          Though anything is superior when it’s already the status quo on a project.

          • JackbyDev
            link
            fedilink
            English
            111 months ago

            I don’t know dude, with YAML treating the word no as a Boolean and having like 6 types of multi line strings I’m really inclined to disagree with the “fewer corner cases” part. It’s like waaaaaaaay less corner cases. Imagine pasting the ISO abbreviation for a country as a Boolean value.

    • Carlos Solís
      link
      fedilink
      English
      411 months ago

      Agreed. YAML is a pain to edit manually, to ensure that all the tabulation is correct and the parser does not choke. JSON is passable, but you must be mindful about the brackets. XML is too verbose and duplicative. INI files are just good enough.

      • That’s why I like TOML. It’s basically INI, but it has more structural features if you need them. Most of the TOML files I use look just like ini files.

      • exu
        link
        fedilink
        English
        311 months ago

        YAML is fine if you use a formatter. JSON’s ok to read but a pain to write imo. INI if it’s simple.

  • @argv_minus_one@beehaw.org
    link
    fedilink
    1111 months ago

    JSON is overly verbose and doesn’t allow comments. Please do not use it for anything that humans frequently need to read or write.

    YAML is a syntactic minefield. Please do not use it for anything ever.

  • @Lanthanae
    link
    711 months ago

    nix

    This post was sponsored by NixOS gang

    (jokes aside, json is king. Yaml is a pain in the ass)

  • Papamousse
    link
    fedilink
    English
    511 months ago

    I’d say a file that you can open with a simple text editor is convenient, so it can be a simple .conf/.ini, more complex are .xml/.yaml that you can still edit in vim/nano but can be cumbersome.

    But as others say, it all depends on your app…

  • The Doctor
    link
    fedilink
    411 months ago

    Not XML. Not binary-only (looking at you, Solaris).

    Personally, I like .ini-style config files, but I’m weird that way.

  • How able Lua?

    It’s a programming language, so you can do fancy stuff, or you can just use it as a regular key value file. You can also safely enable/disable features so you only need to allow the subset of Lua that you need.

    It works really well for things like editor configuration (see neovim), and it’s especially nice if you already use Lua as a plugin language or something.