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.
> 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".
It means we're not confident the API is stable yet. There might be further changes before the final, non-experimental version, depending on user feedback and further experience with the current proposal.
In the case of encoding/json/v2, enabling GOEXPERIMENT=jsonv2 has two major effects:
1. It flips encoding/json (the original, not /v2) to use the new implementation. This is supposed to be a fully backwards-compatible change, modulo some changes to the text of some errors. We're very interested to hear of any cases of existing programs breaking when the experiment is turned on, because (aside from the aforementioned error text, which you shouldn't be depending on) it likely indicates a bug that needs fixing. This is the "new code, please test" half of the change.
2. It enables the new API (encoding/json/v2, encoding/json/jsontext, some new options in encoding/json). This is the "unstable API, might change in response to feedback" half of the change.
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:
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.
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.
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.
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.
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.
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.
> 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.