• thebestaquaman@lemmy.world
    link
    fedilink
    arrow-up
    15
    ·
    10 hours ago

    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. JSON is my friend.

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      4
      ·
      9 hours ago

      They serve largely different use-cases. JSON is good for serializing data. TOML is good for configuration.

        • ell1e@leminal.space
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          4 hours ago

          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?

          • Ephera@lemmy.ml
            link
            fedilink
            English
            arrow-up
            1
            ·
            41 minutes ago

            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.