A new Go API for JSON

At this stage to me Go is the new C compiler. Quite honestly I spent 10 years or more writing Go code. At times 18 hours a day. And now with AI, I get models to write my Go code. I STILL want it to be Go code. Is that strange? No because I understand the performance and safety of Go. But I rarely write it directly anymore. Probably not at all in 6-9 months. Yet I still occasionally look at the code to see what the output looks like.

So yea hopefully a nice new addition but only my prompts now matter. So need to make sure they pickup on the new API.

> "JavaScript Object Notation (JSON) is a simple data interchange format [...]"

Clearly it isn't, otherwise every language would have sorted it out by... a long time 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.

I'm working on better SIMD support in Dart and one of the motivations for that work is specializing parser specifications based on schema specifications of that language.

Or more concretely, if we had a parser generator + json parser specification that can generate efficient simdjson style parsers, then we should be able to parse json restricted to a subset of json based on a schema at least as efficiently as simdjson can parse general purpose json.

That way we could have the best of both worlds, a (potentially lazy) statically type-safe model and simdjson performance!

I still think that this is definitely doable, it's just that a lot of infrastructure needs to be built for it.

I remember reading that Meta is doing something similar with binary formats. I find it weird that there's nothing like that for json yet.

I… think this is good?

I'm just getting the neuron-band back together where Golang is concerned. I have done some in the past for little system tasks, but I am switching away from interpreted languages entirely for web stuff, and initially to Go, as I switch away from hand-coding to at least LLM-supported coding.

So I am a bit out of date on the pain points (I never really felt pain points when I last used it, because the jobs I was doing had very small, quite Go-friendly shapes).

The fact that this took 6 years to land stood out to me.

I'm not entirely surprised, and I'm glad the Go team is carefully considering their interfaces before launching. But 6 years seems like a lot of work to land a JSON API.

I used the jsontext package at my company when we needed to make a parser for challenging clients (specific errors for each kind of mistake) while still keeping performance, and it works like a charm.

There is no introspection and speed is superb. I would definitely recommend jsontext as a parser for anything non-straightforward.

I like it. I never really liked marshalling anyways, It was weird.

I'm happy it's getting fixed!

> nil slices and maps are marshaled as an empty JSON array or object by default

I feel that is the kind of broken default that will come back and bite a bunch of people, and will eventually need to be fixed in a v3.

This is how you roll out features, C++. Congrats to Go team and users.

wohoo, good news indeed better later than never :D as an active Golong user I'm very happy

I think I can build a new web tools serving for this new API

> in any, out any

Completely unrelated: can anyone tell me why language authors introduce in/out/inout function parameters (see also C#).

It feels like this is some rather bad workaround for something that breaks assumptions about parameters being passed into the function.

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

Now guess what will happen when they add monadic error handling. Yes, correct, there will be another JSON Go API

[flagged]

[flagged]

[flagged]

[flagged]