4 ms·

New `encoding/json/v2` package (hidden behind `GOEXPERIMENT=jsonv2` flag)! It brings perf improvements and finally allows devs to implement custom marshalers fo

New `encoding/json/v2` package (hidden behind `GOEXPERIMENT=jsonv2` flag)! It brings perf improvements and finally allows devs to implement custom marshalers for external types: > Alternatively, users can implement functions that match MarshalFunc, MarshalToFunc, UnmarshalFunc, or UnmarshalFromFunc to specify the JSON representation for arbitrary types. This provides callers of JSON functionality with control over how any arbitrary type is serialized as JSON. Awesome stuff.

zx8080 1y ago
Wow, top comment about json. (Edit: not top 1 anymore, but still the point). It's ironic that the information technology and software engineering industry is so much "json parsing and repacking" one.
- trenchpilgrim 1y ago
  To be fair, the existing json package in Go's standard library is somewhat infamous because it is non-streaming, so it has performance issues with large documents. one of the goals of json/v2 was to remedy this.
- gwd 1y ago
  I mean, I get what you're saying, but the fact is 1. Golang is used in web and api servers 2. Json is the lingua franca of data for the web, so golang does a lot of json processing 2. The golang stdlib json packages haven't had much attention in the last decade I was just thinking recently that my biggest pain point with the upstream JSON packages was the fact that you can't add easily add custom marshal / unmarshal code to objects in a package you don't control. I'm actually really excited about this change. The other reason this is at the top of the list, of course, is that there are no major interesting language features being added. This is a combination of the fact that golang is a pretty mature language, and the slowness of the team to adding new language features; both of which I appreciate.
- the_gipsy 1y ago
  The irony is that go has taken the "web backend" niche, yet it sucks notoriously at JSON. It's a complete joke TBH, and no amount of patching can ever fix zero-values, the root of all evil in go.
  - majewsky 1y ago
    Zero values can, for the most part, be caught with a custom UnmarshalJSON implementation (and the new UnmarshalJSONFrom interface ought to remove most of the performance penalty associated with that). The one problem is what to do when the field is missing entirely, because then UnmarshalJSON(From) will never be invoked. I have been thinking about suggesting a new struct field tag for JSON parsing: `json:',required'` that throws an error when the struct field is absent in the respective JSON object. The artifice is mostly in how to phrase that proposal in a way that makes it more likely for the Go devs to accept it. If I just come in like "I hate zero values", that may have some truth to it, but it's not going to be conducive to the discussion going the way I want.
    - the_gipsy 1y ago
      That's the joke: you either make a whole new DSL that is then not even really that typesafe, or you just embrace pushing bad values into your system. Because there is no standard or convention, everybody brings their own "nullable" wrappers between JSON, SQL, and whatnot, that are all half-baked and incompatible. Look at rust/serde to see what it could have been.
  - pjmlp 1y ago
    On my little corner of the universe, "web backend" means Java, .NET or nodejs, the set of languages that can run on top of any of those runtimes.
    - the_gipsy 1y ago
      You're right, go has not "taken it over". I meant more that it has moved into that niche since its conception, while being really bad at dealing with JSON correctly.
pbnjay 1y ago
Yes I was very excited to see the new json encoding changes land, can’t wait to try them out! The new omitempty and map key marshalling in particular will help clean up some of my ugly code.
tete 1y ago
> We expect the design of encoding/json/v2 to continue to evolve. We encourage developers to try out the new API and provide feedback on the proposal issue. Does anyone have more knowledge on what this refers to? I thought v2 being in as an experiment means they are happy with it, but "we expect it to evolve" sounds like "we know it's not good yet". Maybe I am understanding it the wrong way though. Just because other experiments were more like "this is new code, please test" and not "this will change".
- LambdaComplex 1y ago
  Just because the Go maintainers think it's in an okay state doesn't mean the wider community won't have good ideas on how to improve it.
- arccy 1y ago
  Other experiments did change though: arena got dropped, synctest Run -> Test
  - MadcapJake 1y ago
    Where is it mentioned that the arena experiment has been dropped?
    - typical182 1y ago
      The arena experiment was essentially placed on indefinite hold: > The proposal to add arenas to the standard library is on indefinite hold due to concerns about API pollution. I think the parent comment was using arenas as an example that GOEXPERIMENTs don't always move forward (like arenas), or can change while still GOEXPERIMENTs in a way that would normally not be allowed due to backward compatibility (like synctest). The arena GOEXPERIMENT has not yet been dropped as of Go 1.25, but as I understand it, the plan is to remove arenas from the runtime when 'regions' are introduced, which have similar performance benefits but a much lower API impact: https://github.com/golang/go/discussions/70257 https://github.com/golang/go/discussions/70257 As discussed there, seeing how people actually used the arena GOEXPERIMENT influenced the 'regions' design.
kvemkon 1y ago
So now there is at least a workaround to preserve the order when processing JSON. Great! [1] https://github.com/golang/go/issues/27179#issuecomment-2289926502 https://github.com/golang/go/issues/27179#issuecomment-22899...

zx8080 1y ago

Wow, top comment about json. (Edit: not top 1 anymore, but still the point). It's ironic that the information technology and software engineering industry is so much "json parsing and repacking" one.

trenchpilgrim 1y ago
To be fair, the existing json package in Go's standard library is somewhat infamous because it is non-streaming, so it has performance issues with large documents. one of the goals of json/v2 was to remedy this.
gwd 1y ago
I mean, I get what you're saying, but the fact is 1. Golang is used in web and api servers 2. Json is the lingua franca of data for the web, so golang does a lot of json processing 2. The golang stdlib json packages haven't had much attention in the last decade I was just thinking recently that my biggest pain point with the upstream JSON packages was the fact that you can't add easily add custom marshal / unmarshal code to objects in a package you don't control. I'm actually really excited about this change. The other reason this is at the top of the list, of course, is that there are no major interesting language features being added. This is a combination of the fact that golang is a pretty mature language, and the slowness of the team to adding new language features; both of which I appreciate.
the_gipsy 1y ago
The irony is that go has taken the "web backend" niche, yet it sucks notoriously at JSON. It's a complete joke TBH, and no amount of patching can ever fix zero-values, the root of all evil in go.
- majewsky 1y ago
  Zero values can, for the most part, be caught with a custom UnmarshalJSON implementation (and the new UnmarshalJSONFrom interface ought to remove most of the performance penalty associated with that). The one problem is what to do when the field is missing entirely, because then UnmarshalJSON(From) will never be invoked. I have been thinking about suggesting a new struct field tag for JSON parsing: `json:',required'` that throws an error when the struct field is absent in the respective JSON object. The artifice is mostly in how to phrase that proposal in a way that makes it more likely for the Go devs to accept it. If I just come in like "I hate zero values", that may have some truth to it, but it's not going to be conducive to the discussion going the way I want.
  - the_gipsy 1y ago
    That's the joke: you either make a whole new DSL that is then not even really that typesafe, or you just embrace pushing bad values into your system. Because there is no standard or convention, everybody brings their own "nullable" wrappers between JSON, SQL, and whatnot, that are all half-baked and incompatible. Look at rust/serde to see what it could have been.
- pjmlp 1y ago
  On my little corner of the universe, "web backend" means Java, .NET or nodejs, the set of languages that can run on top of any of those runtimes.
  - the_gipsy 1y ago
    You're right, go has not "taken it over". I meant more that it has moved into that niche since its conception, while being really bad at dealing with JSON correctly.

pbnjay 1y ago

Yes I was very excited to see the new json encoding changes land, can’t wait to try them out! The new omitempty and map key marshalling in particular will help clean up some of my ugly code.

tete 1y ago

> We expect the design of encoding/json/v2 to continue to evolve. We encourage developers to try out the new API and provide feedback on the proposal issue. Does anyone have more knowledge on what this refers to? I thought v2 being in as an experiment means they are happy with it, but "we expect it to evolve" sounds like "we know it's not good yet". Maybe I am understanding it the wrong way though. Just because other experiments were more like "this is new code, please test" and not "this will change".

LambdaComplex 1y ago
Just because the Go maintainers think it's in an okay state doesn't mean the wider community won't have good ideas on how to improve it.
arccy 1y ago
Other experiments did change though: arena got dropped, synctest Run -> Test
- MadcapJake 1y ago
  Where is it mentioned that the arena experiment has been dropped?
  - typical182 1y ago
    The arena experiment was essentially placed on indefinite hold: > The proposal to add arenas to the standard library is on indefinite hold due to concerns about API pollution. I think the parent comment was using arenas as an example that GOEXPERIMENTs don't always move forward (like arenas), or can change while still GOEXPERIMENTs in a way that would normally not be allowed due to backward compatibility (like synctest). The arena GOEXPERIMENT has not yet been dropped as of Go 1.25, but as I understand it, the plan is to remove arenas from the runtime when 'regions' are introduced, which have similar performance benefits but a much lower API impact: https://github.com/golang/go/discussions/70257 https://github.com/golang/go/discussions/70257 As discussed there, seeing how people actually used the arena GOEXPERIMENT influenced the 'regions' design.

kvemkon 1y ago

So now there is at least a workaround to preserve the order when processing JSON. Great! [1] https://github.com/golang/go/issues/27179#issuecomment-2289926502 https://github.com/golang/go/issues/27179#issuecomment-22899...