5 ms·

The complaint is mostly about JSON parsers, not the JSON spec itself, which as other comments have said works quite well in practice. In .NET land the most pop

The complaint is mostly about JSON parsers, not the JSON spec itself, which as other comments have said works quite well in practice. In .NET land the most popular JSON library is Newtonsoft which plays fast and loose with the JSON spec and makes a lot of default assumptions. A couple of years ago Microsoft rolled out their own first-party JSON library, which is a lot stricter and requires the developer to explicitly configure the parser instead of making assumptions. https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/migrate-from-newtonsoft?pivots=dotnet-9-0#table-of-differences https://learn.microsoft.com/en-us/dotnet/standard/serializat... But some developers still instinctively reach for Newtonsoft, even when working on brand new projects. In practice, this sort of ingrained habit is far greater of a problem than the JSON spec itself. The author says that Protobuf makes all of JSON's problems go away. I don't know enough about Protobuf to confirm or deny, but I know that it's not tested 10 trillion times a day like JSON is.

theFco 2y ago
The argument that it is tested 10 trillion times a day is a fallacy (because it can't be that only the most popular option should be the best forever). And furthermore, in this context "tested" is a bit of an overstatement, I would say "used" many gazillions of times a day.
- buzzardbait 2y ago
  Using is testing. The whole point of automated UI tests is to mimic usage. A random click on a website might not be a great test, but it is a test nonetheless. And if it fails enough times, someone somewhere will be held accountable.
- dogboat 2y ago
  It is used so much across the board for FE and BE and CI and config. Despite the heavy usage I it hasn't been canned and I have never heard anyone at work complain about JSON for any reason. You could say it is network effects but if it were crap you could replace it much more easily than say moving from Python to Java or whatever. Especially for internal microservice stuff and perhaps front end. JSON and the tooling is basically solid. It is a non-concern.
jchw 2y ago
The complaint that many things are implementation-defined is a (valid) complaint about the spec, though. JSON is essentially just a specification for some syntax. When you actually want a full and well-defined serialization/deserialization format, this can lead to fun surprises with JSON.
marssaxman 2y ago
> not tested 10 trillion times a day Perhaps not, but it might be close: essentially every message sent between every component of every service on every machine in every datacenter Google operates gets encoded as a protobuf. Engineering at Google consists of populating protobufs to send to other services, which reply with protobufs containing the data you need to stuff into more protobufs, which you can then send on to further different services. We can, in other words, safely conclude that protobuf scales.
- dogboat 2y ago
  ROT13 also scales. Anything that uses minimal compute can be embarrisingly parallelizable. I think it is more interesting how protobuf is used. I am not experienced in it but roughly it seems like you design a schema for tight packing data. Therefore there is more work in accepting a protobuf and you cant just add arbitrary fields and let old versions of sdks ignore em. I think! This is good and bad. It is the schema vs schemaless and compile types. vs runtime types. There is also the efficiency of protobuf vs slightly more verbose JSON.
pjmlp 2y ago
We reach out to Newtonsoft, because .NET also has a Python 2/3 problem and not everyone can be on .NET vLatest, or has the budget to rewrite code to use other parsers.
- metaltyphoon 2y ago
  STJ supports netstandard2.0
  - pjmlp 2y ago
    It does, but it also lacks feature parity, and someone has to budget the rewrite. https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/migrate-from-newtonsoft?pivots=dotnet-9-0 https://learn.microsoft.com/en-us/dotnet/standard/serializat...
- neonsunset 2y ago
  I wonder if Pjmlp would become happier if he was to stop working with companies using ancient stacks for no reason whatsoever. Luckily, companies like that are becoming a minority. You do not have to concern yourself with .NET Framework if you do not want to under free market economy :) Also, there was no Python 2/3 - it’s not comparable and there were no breaking changes in the language. You can’t be serious if you think these are equivalent.
  - CRConrad 2y ago
    > companies using ancient stacks for no reason whatsoever. Luckily, companies like that are becoming a minority. Wow. I'd like to live in your world. Where I am, they seem to be the norm.
  - pjmlp 2y ago
    Not everyone has the freedom to chose their employers, or consulting costumers. All companies whose main business isn't selling software have reasons to use ancient stacks, that isn't the money maker, what is deployed in production works, and there isn't budget around for a full rewrite. Also Microsoft could set the example, some of those products are theirs. Yes I am serious, library code also counts. If your identity wasn't so tied with .NET, maybe you would see the transition mess in a bit more impartial way, it is no accident that now they introduced AI based migration tool at Ignite, and are seeking companies willing to try it out.
maximilianburke 2y ago
If the problem is that all the parsers implement a different interpretation of the spec such that you get the kinds of incompatibilities the article lists, that all means that the spec is faulty.
- buzzardbait 2y ago
  The spec might not be perfect, but some of the most popular parsers play fast and loose with the rules. (Looking at you, Newton "I permit //comments in JSON" Soft)
neonsunset 2y ago
Newtonsoft.JSON is no longer the standard choice. System.Text.Json was first introduced 5 years ago and is also provided as a package to support targets as old as .NET Framework 4.6.1.
- buzzardbait 2y ago
  Fun fact: The author of Newtonsoft was/is employed at Microsoft to work on System.Text.Json. It's sort of like a redemption arc.

theFco 2y ago

The argument that it is tested 10 trillion times a day is a fallacy (because it can't be that only the most popular option should be the best forever). And furthermore, in this context "tested" is a bit of an overstatement, I would say "used" many gazillions of times a day.

buzzardbait 2y ago
Using is testing. The whole point of automated UI tests is to mimic usage. A random click on a website might not be a great test, but it is a test nonetheless. And if it fails enough times, someone somewhere will be held accountable.
dogboat 2y ago
It is used so much across the board for FE and BE and CI and config. Despite the heavy usage I it hasn't been canned and I have never heard anyone at work complain about JSON for any reason. You could say it is network effects but if it were crap you could replace it much more easily than say moving from Python to Java or whatever. Especially for internal microservice stuff and perhaps front end. JSON and the tooling is basically solid. It is a non-concern.

jchw 2y ago

The complaint that many things are implementation-defined is a (valid) complaint about the spec, though. JSON is essentially just a specification for some syntax. When you actually want a full and well-defined serialization/deserialization format, this can lead to fun surprises with JSON.

marssaxman 2y ago

> not tested 10 trillion times a day Perhaps not, but it might be close: essentially every message sent between every component of every service on every machine in every datacenter Google operates gets encoded as a protobuf. Engineering at Google consists of populating protobufs to send to other services, which reply with protobufs containing the data you need to stuff into more protobufs, which you can then send on to further different services. We can, in other words, safely conclude that protobuf scales.

dogboat 2y ago
ROT13 also scales. Anything that uses minimal compute can be embarrisingly parallelizable. I think it is more interesting how protobuf is used. I am not experienced in it but roughly it seems like you design a schema for tight packing data. Therefore there is more work in accepting a protobuf and you cant just add arbitrary fields and let old versions of sdks ignore em. I think! This is good and bad. It is the schema vs schemaless and compile types. vs runtime types. There is also the efficiency of protobuf vs slightly more verbose JSON.

pjmlp 2y ago

We reach out to Newtonsoft, because .NET also has a Python 2/3 problem and not everyone can be on .NET vLatest, or has the budget to rewrite code to use other parsers.

metaltyphoon 2y ago
STJ supports netstandard2.0
- pjmlp 2y ago
  It does, but it also lacks feature parity, and someone has to budget the rewrite. https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/migrate-from-newtonsoft?pivots=dotnet-9-0 https://learn.microsoft.com/en-us/dotnet/standard/serializat...
neonsunset 2y ago
I wonder if Pjmlp would become happier if he was to stop working with companies using ancient stacks for no reason whatsoever. Luckily, companies like that are becoming a minority. You do not have to concern yourself with .NET Framework if you do not want to under free market economy :) Also, there was no Python 2/3 - it’s not comparable and there were no breaking changes in the language. You can’t be serious if you think these are equivalent.
- CRConrad 2y ago
  > companies using ancient stacks for no reason whatsoever. Luckily, companies like that are becoming a minority. Wow. I'd like to live in your world. Where I am, they seem to be the norm.
- pjmlp 2y ago
  Not everyone has the freedom to chose their employers, or consulting costumers. All companies whose main business isn't selling software have reasons to use ancient stacks, that isn't the money maker, what is deployed in production works, and there isn't budget around for a full rewrite. Also Microsoft could set the example, some of those products are theirs. Yes I am serious, library code also counts. If your identity wasn't so tied with .NET, maybe you would see the transition mess in a bit more impartial way, it is no accident that now they introduced AI based migration tool at Ignite, and are seeking companies willing to try it out.

maximilianburke 2y ago

If the problem is that all the parsers implement a different interpretation of the spec such that you get the kinds of incompatibilities the article lists, that all means that the spec is faulty.

buzzardbait 2y ago
The spec might not be perfect, but some of the most popular parsers play fast and loose with the rules. (Looking at you, Newton "I permit //comments in JSON" Soft)

neonsunset 2y ago

Newtonsoft.JSON is no longer the standard choice. System.Text.Json was first introduced 5 years ago and is also provided as a package to support targets as old as .NET Framework 4.6.1.

buzzardbait 2y ago
Fun fact: The author of Newtonsoft was/is employed at Microsoft to work on System.Text.Json. It's sort of like a redemption arc.