Meme transcription:

Panel 1: Bilbo Baggins ponders, “After all… why should I care about the difference between int and String?

Panel 2: Bilbo Baggins is revealed to be an API developer. He continues, “JSON is always String, anyways…”

  • RustyNova@lemmy.world
    link
    fedilink
    arrow-up
    41
    arrow-down
    1
    ·
    edit-2
    2 days ago

    To whoever does that, I hope that there is a special place in hell where they force you to do type safe API bindings for a JSON API, and every time you use the wrong type for a value, they cave your skull in.

    Sincerely, a frustrated Rust dev

    • skuzz@discuss.tchncs.de
      link
      fedilink
      arrow-up
      11
      ·
      2 days ago

      “Hey, it appears to be int most of the time except that one time it has letters.”

      throws keyboard in trash

      • Username@feddit.de
        link
        fedilink
        arrow-up
        4
        ·
        2 days ago

        Rust has perfectly fine tools to deal with such issues, namely enums. Of course that cascades through every bit of related code and is a major pain.

        • RustyNova@lemmy.world
          link
          fedilink
          arrow-up
          6
          ·
          2 days ago

          Sadly it doesn’t fix the bad documentation problem. I often don’t care that a field is special and either give a string or number. This is fine.

          What is not fine, and which should sentence you to eternal punishment, is to not clearly document it.

          Don’t you love when you publish a crate, have tested it on thousands of returned objects, only for the first issue be “field is sometimes null/other type?”. You really start questioning everything about the API, and sometimes you’d rather parse it as serde::Value and call it a day.

    • Rednax@lemmy.world
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      2 days ago

      The worst thing is: you can’t even put an int in a json file. Only doubles. For most people that is fine, since a double can function as a 32 bit int. But not when you are using 64 bit identifiers or timestamps.

      • Ethan@programming.dev
        link
        fedilink
        English
        arrow-up
        8
        ·
        2 days ago

        That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.

  • andyburke@fedia.io
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    2 days ago

    These JSON memes got me feeing like some junior dev out there is upset because they haven’t read and understood the docs.

    • RustyNova@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      2 days ago

      If a item can have different type, those label fields are actually quite useful. So I don’t see the problem