To preserve the order when processing JSON a workaround has been introduced:

https://news.ycombinator.com/item?id=44893833

Still searching the true solution:

https://github.com/golang/go/issues/27179#issuecomment-53634...

A proposal of the missing datatype for this operation mode has been just accepted:

https://github.com/golang/go/issues/69559

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

> "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 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… 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.

This v2 idea in the stdlib should have started even earlier. So I am glad we are getting a better API for json/v2.

This pragmatic attitude towards software engineering is exactly why I still reach for Go for pretty much everything these days. I still read and review code.

So working with a language that doesn't throw a splash of sigil soup on my face is quite nice while reviewing clanker output. Also, being able to do all this without needing 5 crates is nice. Oh the fast build time helps too.

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.

There is the superset of JSON known as JSON5. But A.I. tells me that nobody has (yet) built a JSON5 implementation that builds on encoding/json/v2 .

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

I'm happy it's getting fixed!

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

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

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

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

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

"There only ONE way to do each thing! Only ONE! No exception"

"What if it sucks?"

"There are now TWO ways to do each thing! No more than TWO! I promise!"

It's like python again.

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

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