Is erlang too small?

[Jeffrey M. Einhorn]

Would the maintenance cost to actually include common libraries like
xmerl and edoc be prohibitive?  

The Java Community Process and Python Enhancement Proposals are examples
of two very successful initiatives that have helped increase the
productivity of developers that use those languages.  The inclusion of
common libraries(xmerl) sets a standard that provides consistency in the
development of software that deals with XML.  Another benefit of rolling
open-source library projects into the languages core is that these
libraries receive an immediate increase in visibility.  This increase in
visibility often leads to major improvements to the libraries after they
are initially included.  In addition these additional standard libraries
increase the marketing power of a language by providing new features
that can lure new developers into trying the language.   

The CPAN approach does provide a rich set of libraries, but it suffers
from several key shortcomings.  First their are often lots of libraries
that do similar things, which often leads to a lack of consistency in
how common tasks are accomplished.  Secondly because developers have to
go out of their way to actually install a CPAN module leads to many
modules that are not used very often and suffer a lower quality as a
result.

In summation as an Erlang developer I would like to see its user base
continue to grow and I feel including additional libraries would help
that cause by making current developers more effective and increasing
the features that might convince new developers to give the language a
try.
	Thanks for Erlang/OTP,
		-jeff einhorn

On Mon, 2004-05-10 at 22:47, Shawn Pearce wrote:
> Rudolph van Graan <rvg@REDACTED> wrote:
> > It goes like this... Recently, we've been working on a number of 
> > projects, two of which needed some XML and some needed http interaction 
> > (using http requests). In both cases, I've run into some bugs somewhere 
> > in Erlang which I just didn't want to trace, mostly because of a lack 
> > of time. [snip]
> 
> You mention switching to Java.  Yet today I spent 9 hours debugging what
> looks to be a bug in the Java garbage collector.  My nice, clean(*) Java
> application that used a steady 20 MB of memory has now suddenly begun to
> use about 5 MB per window the user opens.  And when the user closes the
> window, the JVM happily keeps the memory leaked.  I spent the entire day
> trying to track down who holds the final reference(s) to the object graph
> to get the data cleaned up - to no avail.  What a waste of a day.  Now
> I've just got to document this as a known bug and move on, we just don't
> have this kind of time to waste on debugging high quality tools such
> as Java.
> 
> So all day long I sat there going "*!*@#*@&*!* if this was in Erlang I
> wouldn't be having this problem! @#!*!*!* Java!".
> 
> And I get home and read your skipping out of Erlang to Java because
> Erlang doesn't work sometimes.  :)
> 
> (*) - Here I mean "nice, clean" as in the damn thing doesn't currently
> consume 1 GB of memory to complete a simple task, but instead actually
> seems to run reasonably well for about 10 minutes at a time.  Until
> I added this new feature that is.
> 
> 
> As far as the things you mentioned that need better support in Erlang
> (perhaps just more documented support?), every one of these is a "core"
> CPAN module.  (By "core" I mean one that is very heavily used in almost
> all Perl projects eventually.)
> 
> Aside from using Perl for CGI programming on UNIX boxes back in the day,
> CPAN is what made Perl Perl.  Its relatively clean DBI, LWP, XML::*,
> MD5, and MIME modules were very critical to Perl's success as a language.
> I'm not sure how CPAN is governed, but somehow its worked well at keeping
> a nice namespace where good packages occupy the "good" names, and the
> rest is kept out.
> 
> 
> Wasn't jungerl trying to provide an CEAN (Comprenshive Erlang Archive Network)?
> Its a good place to start, but I haven't even tried jungerl as its just too
> much to download.  :)
> 
> 
> I know one problem with Erlang is I just can't get a full time project
> going in Erlang.  So I don't put a whole lot of effort into things I
> was trying to do, like gen_serial.  :)  I suspect many people here have
> similiar issues; they just can't dedicate the amount of time needed to
> make good libraries for Erlang.  They get it close enough for their
> needs and move on.
> 
>