Can you explain why? This seems like the appropriate expectation to me, given how JSON is constructed and consumed.

[delayed]

I think it'll bite some people, but probably is the better default for JSON specifically. Most of the nil-maps-become-null thing is just an extension of Go defaulting to nil for empty arrays and maps, which is usually not what you expect when you're writing a JSON schema like

    type ListUsersResponse struct {
        Users []User `json:"users"`
    }

in Go. It's pretty common have code like

    userRows := db.Query(...)
    var users []api.User
    for _, user := range userRows {
        users = append(users, api.User{...})
    }

where you don't _really_ intend for the default nil-ness to leak out. (Apologies for any broken syntax, I'm realizing in real time that it's been a while since I've written Go)

> Most of the nil-maps-become-null thing is just an extension of Go defaulting to nil for empty arrays and maps, which is usually not what you expect when you're writing a JSON schema

This is definitely not what I expect in other language. I would argue this is a quick of Go though and not JSON's fault.

How is this a broken default? In Go, I almost always want a nil slice to be treated exactly as an empty slice, and JSONv1 was the ~only place this didn’t work as expected, leading to frequent bugs.

JSON often means data is crossing a boundary, and JSON has `null`. So if you have a PATCH endpoint that accepts a partial object, how do you determine what was actually set in the request vs what go has initialized to an empty value.

Use the same `Option[T]` type that you will need to define for strings and numbers and structs.

What was the solution before go had generics? I thought it was nil pointers.

I don’t think there was a single canonical solution, but pointers to everything was a pretty common one. Everything in the AWS SDK was a `string` or a `float64` or similar—it was exceedingly annoying, not least of all because it basically forced tons of unnecessary allocations.

The root cause is this idea of "zero values". Any de/serialization in go will always be crutchwork of guessing and incorrect validation.

Just look at the inane rules for map and slice access, what gets nil and what is panic. Even if that were consistent, then you'd still left to wonder if json.field was truly zero or not there.

In Golang a nil value is semantically an empty container. You wouldn't want this translation in Java but in Golang it makes sense.