Re: JSON in OTP

On Mon, Nov 2, 2020 at 10:39 PM Viktor Söderqvist <[email protected]>
wrote:

> Is it time to re-evaluate adding json:{encode,decode}/1 in OTP? Or are
> the arguments against it still valid?
>
>
Different JSON encoders tend to have different guarantees and behavior. If
you include one in the stdlib, you take on a certain maintenance burden on
top of a selection of properties. Chances are people will still pull a
library from the outside which suits their use case better for their
problem space. One of the peculiar things about JSON is that it is slow to
parse, and people tend to use it for large chunks of data. This combination
is slowing down lots of software, unless the encoder/decoder is
particularly fast. Also, it suggests people should compress their data
streams, which isn't a solution: the data simply blows up in memory and
still takes a good while to parse.

In turn, it means you have to make a number of hard trade-offs in a JSON
library, which are far from easy to make and maintain.

I'm not against blessing one library to become the de-facto standard, but
one should definitely make sure to document the trade-offs made in the
library, or you risk people mis-using it. I'm also not against putting a
library in the stdlib. But if done, you would have to remove something
else, and some of the already included format coders are quite abundant in
telecom, I'm afraid.


-- 
J.