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

I am using local LLMs and Go has a bunch of strengths where smaller contexts are concerned; less complicated flow of control being one of them.

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 most people who use JSON don't want strong typing or to use schemas. If you do, you just use a different serialization format: JSON is designed to be a generic, human-readable way to basically represent any kind of data structure (since it deserializes to JS objects). So everything about JSON is working against you if you do try to enforce type/schemas on it.

A grpc-like protocol with more prescriptive type registries/discovery (over the network) and better interop with http (like grpc-gateway) would be the best approach IMO. Definitely not JSON schema

https://dl.acm.org/doi/pdf/10.1145/2714064.2660241

https://dl.acm.org/doi/pdf/10.1145/3314221.3314625

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.

  v := jsontext.Value(b)
  v.Indent()
  fmt.Println(string(v))

    func WithIndent(indent string) Options

    json.Marshal(v, jsontext.WithIndent("  "))

?

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.

JSON processing, quite markedly, is renown in Go for being slow, so I don't really understand why it took so long

I kind of like that the standard library doesn’t move fast. It makes it easier to fit the ecosystem into my head (unlike, for example, the JavaScript ecosystem where I find code doesn’t survive 2 years before failing to compile).

But I do agree that slow and steady produces its own problems. Your example of generics is a good one. But think the example of Go modules is another, perhaps even better, example of how sometimes the Go team really should have accelerated their efforts on.

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

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.

Because they are common types, makes sense to precautionary have the error return.

Not necessarily. Among other things, MarshalJSON methods called during marshaling can return an error for whatever reason the developer sees fit - one possibility that comes to mind is that part of the object tree being marshalled is lazily loaded, and failed to do so.

And, as others have mentioned, there are types like "any" whose marshalability can't be determined at compile time. Those types aren't necessarily at the top level, either; they could appear anywhere in the object tree.

Plus the point of the marshal interface is that it’s reusable.

If you wanted type safety with JSON in Go then don’t use the marshal interface. Period.

Go has this concept baked into the language. For example read and write interfaces so you can write data to an endpoint without having to worry about whether it’s a file system object, TCP/UDP socket, gzip achieve, and a plethora of other options too.

It’s a nice convenience feature and makes up considerably for the restrictions that the Go type system places.

And if you need higher performance code, or compile time safety, or have any other constraints that limit your ability to use these generalised interfaces, then you can use different APIs from the Go standard library to achieve the same thing.

You don’t need to call json.Marshal() if you don’t want to. It’s an option, but it’s just one API into the JSON toolbox.