Ok so nothing is simple then?

Some languages have a culture of doing things correctly and abiding strictly with 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 imprecisely implementing the spec, because 1e10000000 is a perfectly valid JSON number that is beyond the typical IEEE754 implementation of floating point numbers; does your language handle that correctly? Haskell does.

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

The spec (RFC 8259) leaves various leeways 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.

At then there’s more vagaries with JSON schema.

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?

Which C standard? ANSI C? C99?

C99 and all subsequent versions.

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

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.

The thing is this goes both ways. For example, JSON with duplicate keys is valid JSON, and the standard specifies two ways to handle them. To support all ways JSON is used, an implementation will have to provide for both ways, and decide which one to pick as the default. The stricter default on the parsing side is at the same time the less interoperable one. Same for numeric precision: seamlessly allowing higher precision on the generating side lowers interoperability, while accepting it on the parsing side increases interoperability (but also places higher demands on the consuming application). So what do you do? There is no easy and simple answer.

Meet the "Simple Object Access Protocol": https://www.w3.org/TR/2000/NOTE-SOAP-20000508/

Simple data format does not imply that API to work with it is easy to get right.

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?

I mean, it is better than the disaster that is CSV...

It IS a simple format. And you can make a parser yourself very easily. Doesn’t mean that it will be the fastest or most memory efficient. Don’t confuse format and implementation

The spec itself is simple, but different libraries are written that optimize for different things: parsing speed, streaming parsing, minimal memory usage, very very large data, distributed storage, etc.