• Ephera@lemmy.ml
    link
    fedilink
    English
    arrow-up
    30
    ·
    edit-2
    1 day ago

    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.)
    • CreamyJalapenoSauce@piefed.social
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      5 hours ago

      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.