upvote
Meet the "Simple Object Access Protocol": https://www.w3.org/TR/2000/NOTE-SOAP-20000508/
reply
Some languages have a culture of doing things correctly and conforming strictly to the spec. These languages have indeed sorted it out years ago. Haskell for example. Any language that doesn’t have a special number type for JSON is a half-assed implementation, because 1e1000 is a perfectly valid JSON number that is beyond the typical IEEE754 double precision floating point numbers; does your language handle that correctly? Haskell does. This is but a small example of a strong culture bias towards correctness.
reply
Ironically Go has(d) json.Number which almost no one used, so it got dropped from v2: https://pkg.go.dev/encoding/json#Number

You can still use it though, and I built my tiny decimal library around it: https://github.com/ncruces/decimal

reply
The spec (RFC 8259) leaves significant leeway to implementations:

A JSON parser MAY accept non-JSON forms or extensions.

An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings.

Add to that things like duplicate keys being allowed by the spec. There’s a lot of implementation choices to decide on.

And then things can get really complex with JSON Schema.

reply
Yeah that’s what I mean by strictly. Does your implementation take shortcuts or does it hold itself to a higher standard and not do that? Does it only use available memory as the ultimate limit?

A lot of specs contain these optional limitations. The C standard allowed implementations to truncate variable names to 31 characters if they have external linkage and 63 if internal linkage. Would you be happy if your implementation actually does that? Of course not. Neither LLVM nor GCC does that. That’s because people writing compilers also hold themselves to a higher standard. Now imagine this kind of attitude being pervasive.

reply
I don't get your argument here. You say Haskell conforms strictly to the spec and that's a good thing, okay. But then if the C spec allows for truncated names, a compiler could strictly follow the spec and truncate names. So strictly following the spec is not in fact the whole story
reply
Yeah very sorry for the confusion. I should not have used the word strictly. I explained my definition of strictly in the above comment and it’s not really strictly in the dictionary sense. I apologize for my bad writing.
reply
Which C standard? ANSI C? C99?
reply
deleted
reply
My company uses JSUN (/sarcasm) where O = object, and U = union.

Who knew the same object could have completely different definitions based on some flags?

reply
Simple data format does not imply that API to work with it is easy to get right.
reply
I mean, it is better than the disaster that is CSV...
reply
Ok so nothing is simple then?
reply