Surely "1337" is the same as 1337, right?
Surely "1337" is the same as 1337, right?
Meme transcription:
Panel 1: Bilbo Baggins ponders, “After all… why should I care about the difference between int and String?
Panel 2: Bilbo Baggins is revealed to be an API developer. He continues, “JSON is always String, anyways…”
To whoever does that, I hope that there is a special place in hell where they force 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.
Sincerely, a frustrated Rust dev
Relax, it's just JSON. If you wanted to not be stringly-typed, you'd have not used JSON.
(though to be fair, I hate it when people do bullshit types, but they got a point in that you ought to not use JSON in the first place if it matters)
As if I had a choice. Most of the time I'm only on the receiving end, not the sending end. I can't just magically use something else when that something else doesn't exist.
Heck, even when I'm on the sending end, I'd use JSON. Just not bullshit ones. It's not complicated to only have static types, or having discriminant fields
You HAVE to. I am a Rust dev too and I'm telling you, if you don't convert numbers to strings in json, browsers are going to overflow them and you will have incomprehensible bugs. Json can only be trusted when serde is used on both ends
This is understandable in that use case. But it's not everyday that you deal with values in the range of overflows. So I mostly assumed this is fine in that use case.
These JSON memes got me feeing like some junior dev out there is upset because they haven't read and understood the docs.
You guys have docs?
You guys can read?
Comments? Comments? Who needs comments?
I'll have you know all of my code is stringly typed.
All my binary code is stringy too.
CBOR for life, down with JSON.
Hell, no. If I wanted to save bytes, I’d use a binary format, or just fucking zip the JSON. Looking at a request-response pair and quickly understanding the transferred data is invaluable.
If you're moving away from text formats, might as well use a proper serialisation tool like protobuf...
Explicit types are just laziness, you should be catching exceptions anyways.
I do. I return an error.
It's the API's job to validate it either way. As it does that job, it may as well parse the string as an integer.
I refuse to validate data that comes from the backend I specifically develop against.
json doesn't have ints, it has Numbers, which are ieee754 floats. if you want to precisely store the full range of a 64 bit int (anything larger than 2^53 -1) then string is indeed the correct type
Let me show you what Ethan has to say about this: https://feddit.org/post/319546/174361
json doesn’t have ints, it has Numbers, which are ieee754 floats.
No. numbers in JSON have arbitrary precision. The standard only specifies that implementations may impose restrictions on the allowed values.
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
A string that represents types...
If a item can have different type, those label fields are actually quite useful. So I don't see the problem
This is String - you’ve seen it before haven’t you, Gollum?
The comment section proves that xml is far superior to json
XML is all round better than Json.
Protocol Buffers are hated, but they are needed.
Do you actually use them?
I'm a student so, yes and no?
I do, but I also don't think that's a silver bullet, unfortunately. There's convenience in code generation and compatibility, at least