• CreamyJalapenoSauce@piefed.social
    link
    fedilink
    English
    arrow-up
    31
    arrow-down
    1
    ·
    3 days ago

    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 [].

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      38
      ·
      edit-2
      3 days 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
        3
        ·
        edit-2
        2 days 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.

        • Decq@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          13 hours ago

          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).

          • crater2150@feddit.org
            link
            fedilink
            arrow-up
            1
            ·
            4 hours ago

            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)