A New Go API for JSON

(go.dev)

60 points | by olexsmir 1 hour ago

2 comments

  • CamouflagedKiwi 38 minutes ago
    I generally like `encoding/json/v2` and I'm glad they did it.

    I wish they'd left `MarshalIndent` in there though. The equivalent code is super complicated and non-obvious, so it's a pain to migrate, and it's a pain when you're banging out some quick code and want to dump some readable JSON. I suppose these days the LLMs can write the complicated version for us, of course.

  • lolpanda 44 minutes ago
    the marshal api has been very annoying. why does marshal return an error? the only reason the marshal can return an error is that the input type is not marshalable. it's certainly a code bug. to me it's like int+str returning an error instead of compiler error
    • iaaan 3 minutes ago
      It is trivial to ignore an error in Go if you know your use case cannot result in one. But at the end of the day, json.Marshal takes an `any` as a parameter, so it must return an error.
    • leetrout 37 minutes ago
      JSON is a runtime input of unknown type but in your example those are known types so the compiler can catch them.
    • hnlmorg 38 minutes ago
      I wouldn’t class unmarshallable data as a compile time error.

      Plus the point of the marshal interface is that it’s reusable.

      • thayne 13 minutes ago
        It could be if go had a more powerful type system.
        • hnlmorg 7 minutes ago
          This isn’t a type system problem. It’s a data origin problem. Ie it could be any random JSON blob a user entered. The compiler doesn’t know this ahead of time.

          If you wanted type safety with JSON in Go then don’t use the marshal interface. Period.

    • NoDodgeQuestion 14 minutes ago
      do not know at compile time that input is not marshalable, every language marshal must return error for this reason, not only golang