3 ms·

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 s

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

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