[erlang-questions] Is erlang a web language?

[Nick Gerakines]

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
>