<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 7, 2015 at 3:34 AM, Theepan <span dir="ltr"><<a href="mailto:vasdeveloper@gmail.com" target="_blank">vasdeveloper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Since Erlang is now widely used in internet domain, I believe that inclusion of JSON library under STDLIB is essential. There are many open source variants, but I like Jiffy and Jsx. They support MAPS too.</div><div></div></blockquote></div><br></div><div class="gmail_extra">Roughly, two variants of programming language standard libraries exist, where most languages sit somewhere on the continuum of these extreme points:<br><br></div><div class="gmail_extra">1. Put as little as possible in the standard library. Usually only put the things necessary to write the compiler itself, and the libraries which are impossible to write without close support from the compiler/runtime.<br><br></div><div class="gmail_extra">2. Use the Stdlib to "bless" certain implementations of commonly used libraries as the default. The Stdlib is considerably larger, but is guaranteed to have seen lots of testing.<br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">It is not a priori clear one solution beats the other. There are advantages and disadvantages to both models. Personally I lean toward option 1, because I "come from" languages which used this model: Standard ML and OCaml. The danger of such a model however is that you end up with many stdlib implementations, and in statically typed languages you often end up in situations where packages built for one stdlib are not compatible with the other stdlib.<br><br></div><div class="gmail_extra">This makes people yearn for option 2. But it is not without its consequences either. Work on the stdlib is now centered around a few people, so it will invariably move slower. The other problem is that updates to the stdlib is now locked to the update rate of the compiler. This is rarely desirable. And when new releases come out, everyone has to scramble in order to upgrade everything in the stdlib they rely on. In a more compartamentalized world, you can go update packages separately.<br><br></div><div class="gmail_extra">JSON is particularly nasty because different characteristics are mandated by different users. Some want fast JSON parsing. Some want correct JSON parsing. Some want mapping rules into their Erlang world. For this reason, there are always many disparate JSON libraries in any language (C has at least 10, Java has at least 20). You *can* pick one and put into the stdlib, but people still have to build their own to their wants.<br><br></div><div class="gmail_extra">In my opinion, there are far too many libraries in the standard Erlang/OTP distribution. This means more work on the Ericsson Erlang/OTP team and we can't mint a new fix package for a separate area without rolling a new point release for Erlang/OTP. Moving some things into separate repositories would help a lot. But it also requires some work on package management so the transition is as seamless as possible.<br><br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">J.</div>
</div></div>