[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]

Garrett Smith <>
Tue Feb 18 00:26:01 CET 2014

On Mon, Feb 17, 2014 at 9:58 AM, Mark Allen <> wrote:
> On 2/17/14 8:50 AM, "Garrett Smith" <> wrote:
>>Grabbing required source into a single directory and compiling
>>everything, independent of shared system code, is, in my experience,
>>much more reliable.
> I agree with you here


> to the extent that it effectively replicates an
> isolated development environment much like virtualenv or rvm provide for
> Python or Ruby.

Oh :(

>>I think I'm going to call this a feature, not a bug.
> TL;DR:  When it's *obvious* there is a great Erlang implementation of X,
> github is fine. Otherwise, it is totally crappy.
> To encourage broader adoption, Erlang *does* need some kind of maintained
> package index that roughly consolidates the community's package
> preferences into something more meaningful than "I needed to support
> function X in Erlang and I found these 3 projects using Google."
> Because that's a crazy way to expect n00bs to find solutions to real
> problems they're having.
> I assure you as someone who "recently learned" Erlang - about 18 months
> ago - I cannot count the number of times I have started working on
> implementing a story for my $JOB and frittered away an hour or three
> searching Google and github.com looking for "<foo> Erlang" before I
> reinvent the wheel.
> The simple fact is that if you're not part of the "Erlang community" via
> this mailing list or what have you, you will at best find pointers to half
> completed abandon ware on Google code, obscure blog posts written three
> years ago and so forth.
> There have been several times when rather waste time implementing
> "WebService-X for Erlang" I just go ahead and use the official Python
> library hanging off a RabbitMQ consumer.

Seriously, brilliantly put. Completely correct.

The isolation of statically bound, compiled dependencies is a great
technical advantage, but the murk and mire leading up to that is
pointless friction.

Now, there are some here who think these barriers are good and
separate the talented brilliant, tasty, wheat from the dull, lazy,
meager chaff. But we don't mind helping the special folk get along
easier in Erlang land, do we?

I like that github is the point of focus here - it reflects common
practice and is an easy proving ground for new ideas.

And some metadata tacked onto a repo is painless and evolvable. Once
it solidifies, we can pass it along to Pieter to formalize as a


More information about the erlang-questions mailing list