[erlang-questions] Is erlang a web language?

[Dale Harvey]

2009/2/12 Nick Gerakines <nick@REDACTED>

> I'd like to step in and say that Erlang is an awesome platform for
> writing web services. In fact, to back that statement up, I'll let you
> metaphorically peak into how we are using it for just that.
>
> Here at EA we are building a pretty large web service powered by
> Erlang to support different parts of the EA Online group. We've been
> using tools like MochiWeb, etap (github.com/ngerakines/etap), protocol
> buffers (github.com/ngerakines/erlang_protobuffs), dynomite
> (github.com/cliffmoon/dynomite) (CAVEAT: it's unofficial/unimplemented
> but we've got use cases that jive), log_roller
> (github.com/JacobVorreuter/log_roller), ejabberd and list goes on.
>
> To get it out of the way: No, we aren't building a game or MMOG with
> Erlang.
>
> Why? Because Erlang comes with the tools we need to rapidly prototype,
> improve and deliver production quality code. We can light up a small
> grid of modular services that tie into a public facing API within a
> day's development time. It's working really well and I sincerely hope
> that once more of our project is public, I'll be able to speak more on
> it. What you can do is follow us (ngerakines, JacobVorreuter, Tivoli)
> on GitHub and see what open source projects are coming out of this and
> what we are improving on.
>
> # Nick Gerakines
>
> 2009/2/12 Dale Harvey <harveyd@REDACTED>:
> > 2009/2/12 Matthew Palmer <mpalmer@REDACTED>
> >>
> >> On Thu, Feb 12, 2009 at 09:12:55AM -0800, Kevin Scaldeferri wrote:
> >> > On Feb 12, 2009, at 7:53 AM, Joe Armstrong wrote:
> >> > > No language serves up library code to you on a plate with no effort
> >> > > involved.
> >> >
> >> > This is true, but OTOH, Erlang requires much more effort than many
> >> > other language (Perl being the gold standard here, I would say; with
> >> > Ruby and, increasingly, Haskell making good showings).  A good
> >> > repository of reusable code is a huge boon to a language.
> >>
> >> When you find "a good repository of reusable code", for any language,
> >> please
> >> let us know.
> >>
> >> The examples I'm most familiar with (PECL, CPAN, Rubyforge) are large
> >> collections of utter crap, with the occasional jewel to keep your hopes
> >> alive.  The vast majority of what's in any of them is buggy, limited in
> >> scope, doesn't do what it says on the box, poorly tested, undocumented,
> >> downright dangerous, conflicts with other stuff you've already picked,
> >> and/or depends on other modules that you either can't find or which fit
> >> the
> >> previous categories.
> >>
> >> Basically, "a large library of third-party modules" isn't something you
> >> want
> >> to be relying on when you're on a deadline to produce something
> >> mission-critical.  Yes, your average webapp doesn't really fit that
> >> "mission
> >> critical" profile (at least, not in the same way as a telephone switch)
> >> and
> >> hence isn't Erlang's "traditional" market.  Half-arsed injuhnearing
> works
> >> well enough for a webapp; it doesn't work for something where 5-nines
> >> uptime
> >> is a failed product.
> >>
> >> Personally, as an Erlang n00b, I like the different philosophies
> embodied
> >> in
> >> Erlang and it's surrounding community.  I've gotten sick of half-arsed
> web
> >> frameworks and the dodgiest of dodgy code hanging on by the skin of it's
> >> teeth.  I'm looking forward to building some slightly more robust
> systems
> >> from here on.
> >>
> >> - Matt
> >
> > Erlang is written on top of "a large library of 3rd party modules"
> > I dont think your point was to not depend on erlang?
> >
> > Should people use yaws, mochiweb, iserve, crary, or write
> > their own web server for each application?
> >
> > If people are forced to write add hoc implementations of
> > common problems that have been solved X times already, then libraries are
> > doomed to be badly written, documented and tested.
> >
> > right now there are lots of well and badly written public libraries
> > that cover lots of the common utility functions, however integrating
> > them is often annoying, people are wary because they dont know
> > which are the "bad" or the "good" projects, people cant find or
> > search them.
> >
> > It seems unlikely that the "good" libraries will be introduced
> > into otp, especially ones that are more web focused.
> >
> > I think a good package manager solves a lot of those problems,
> > cean is older and doesnt seem to have gained traction, faxien
> > seemed to have early teething problems but is looking like it could
> > be maturing.
> >
> > http://erlware.org/documentation/index.html
> >
> > erlangs core doesnt need to be bloated to solve every problem well
> > and 3rd party libraries dont need to be badly written and untested.
> >
> >>
> >> --
> >> I am cow, hear me moo, I weigh twice as much as you. I'm a cow, eating
> >> grass, methane gas comes out my ass. I'm a cow, you are too; join us
> all!
> >> Type apt-get moo.
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
>

Heh I wanted to make it clear if it wasnt from my first post that
I also think erlang makes for a great platform to write web applications.
having an embedded database and a proliferation
of web servers to choose from are 2 big wins, and the principles
behind erlangs fault tolerance and concurrency orientated
programming are a great match.

I agree with joe's premise that those advantages outweigh the
disadvantages of not having a lot of the common utility libraries
for a lot of people, but I dont agree that its a reason not to bother
providing them as a community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090212/7465a3d3/attachment.htm>