                                                                                                                                                                                                                                                                
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
Message-ID: <0cc53c319c28f5f088a4039eb8a3daa8.squirrel@oinksoft.com>
In-Reply-To: <mailman.5.1349172000.28626.erlang-questi...@erlang.org>
References: <mailman.5.1349172000.28626.erlang-questi...@erlang.org>
Date: Tue, 2 Oct 2012 10:18:25 -0400
From: "Thomas Allen" <tho...@oinksoft.com>
To: erlang-questi...@erlang.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Importance: Normal
Subject: Re: [erlang-questions] Erlang http servers
Precedence: list
Reply-To: tho...@oinksoft.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

> "The standard library is where modules go to die"
> http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/
> This is from python world, and is very obviously seen in Erlang.

Could you cite some examples of third-party libraries being absorbed into
the Erlang/OTP distribution and "dying"? Perhaps this is not as obvious to
everybody as you think.

> Alternatively https://npmjs.org/ has 15k+ packages, we dont need to add
> user management and the kitchen sink to inets, we need to remove it from
> the standard library and promote userland packages as first class citizens
> (ie pick a tool to install packages and bundle it)

I couldn't disagree with that much more ... npm/Node.js is cluttered with
packages of dubious quality that are not maintained in the slightest, and
while this "Wild West" they prefer may seem exciting, I do not think it
bodes well for the long-term stability of projects that depend on these
packages.

If some particular functionality becomes used in a large body of Erlang
projects, it should certainly be brought into the stdlib. Per your Python
reference, one need only look at the "json" module for an example where
bringing something into the stdlib has made deployment and maintenance of
Python code-bases simpler -- no more installing the "simplejson" package,
docs right there on docs.python.org, and JSON earning first-class status
as a serialization format for Python objects.

To advocate actually removing things from the Erlang stdlib, potentially
breaking working code on a large scale, is madness to me.

Thomas Allen

_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions