To whoever does that, I hope that there is a special place in hell where they for you to do type safe API bindings for a JSON API, and every time you use the wrong type for a value, they cave your skull in.

The worst thing is: you can’t even put an int in a json file. Only doubles. For most people that is fine, since a double can function as a 32 bit int. But not when you are using 64 bit identifiers or timestamps.

That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.

What that means is that you cannot rely on numbers in JSON. Just use strings.

Unless you’re dealing with some insanely flexible schema, you should be able to know what kind of number (int, double, and so on) a field should contain when deserializing a number field in JSON. Using a string does not provide any benefits here unless there’s some big in your deserialzation process.

What’s the point of your schema if the receiving end is JavaScript, for example? You can convert a string to BigNumber, but you’ll get wrong data if you’re sending a number.

What makes you think so?

const bigJSON = '{"gross_gdp": 12345678901234567890}'; JSON.parse(bigJSON, (key, value, context) => { if (key === "gross_gdp") { // Ignore the value because it has already lost precision return BigInt(context.source); } return value; }); > {gross_gdp: 12345678901234567890n}

developer.mozilla.org/en-US/docs/Web/…/parse

Because no one is using JSON.parse directly. Do you guys even code?

It’s neither JSON’s nor JavaScript’s fault that you don’t want to make a simple function call to properly deserialize the data.