Discussion:
Is erlang a web language?
(too old to reply)
getyourcontacts (Yang Zhang)
2009-02-11 16:46:31 UTC
Permalink
I saw eralng has its own webserver and distribute database. These
looks quite good.
But after I wrote some web programs, I found erlang even doesn't have
a strong enough htmlentities or urlencode , urldecode function. What's
the problem here?
Isnot erlang a web language?
masklinn (Masklinn)
2009-02-11 17:09:44 UTC
Permalink
Post by getyourcontacts (Yang Zhang)
I saw eralng has its own webserver and distribute database. These
looks quite good.
But after I wrote some web programs, I found erlang even doesn't have
a strong enough htmlentities or urlencode , urldecode function. What's
the problem here?
Isnot erlang a web language
I'm not really sure of what you mean by "a web language but:
* if you mean "a language in which it's possible to write a website,
then erlang works (yaws, erlyweb, mochi*)
* if you mean "a language made to create websites (php, coldfusion)
then definitely not
* if you mean "a language in which writing websites is enjoyable
(python+django, ruby+rails) then I'd tend to say no, but I'm sure
others will disagree.

And in any case, Erlang doesn't bundle website-related stuff in the
stdlib. It's not "web ready out of the box", that's not its main usage
domain.
kevin (Kevin Scaldeferri)
2009-02-11 17:35:03 UTC
Permalink
Could you be a little more specific about what "not strong enough"
means?

This complaint is almost comical. Entity encoding and url escaping
are nearly trivial code. Someone has given you a distributed database
and you're brushing it off because you might have to write 20 lines of
code that require practically no thought?


-k
Post by getyourcontacts (Yang Zhang)
I saw eralng has its own webserver and distribute database. These
looks quite good.
But after I wrote some web programs, I found erlang even doesn't have
a strong enough htmlentities or urlencode , urldecode function. What's
the problem here?
Isnot erlang a web language?
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
taavi (Taavi Talvik)
2009-02-11 18:27:46 UTC
Permalink
Post by getyourcontacts (Yang Zhang)
I saw eralng has its own webserver and distribute database. These
looks quite good.
But after I wrote some web programs, I found erlang even doesn't have
a strong enough htmlentities or urlencode , urldecode function. What's
the problem here?
Isnot erlang a web language?
htmlentities, urlencode/decode are easy part. Supplied by
any erlang web frameworks.

It starts to be interesting there:

Web chatroom in 57 lines:
http://nitrogenproject.com/web/samples/comet2

Million connections:
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/

putting data into cloud:
http://couchdb.apache.org/
http://aws.amazon.com/simpledb/

wikipedia on on fraction of hardware:
http://www.onscale.de/scalaris.html
http://www.onscale.de/Schuett_Google_Scalability.pdf

best regards,
taavi
getyourcontacts (Yang Zhang)
2009-02-11 18:58:05 UTC
Permalink
Thanks all for replying.

Just think erlang's database and distribute feature are so great so it is
the best way I can think to make a distribute crawler and web page
analyzor(what I am doing), then found it doesn't have strong built in web
library like urlencode/htmlentities for me to process url and html. And it
builtin httpclient even ibrowse doesn't support bind IP when initial http
request.

Never mind a function is complex or easy, what in my mind is erlang didn't
have it so it is incomplete. No one like to write the simple code again and
again. And I'm not sure I could write it right one the first time i wrote
it. Glad see it has another library to compensate the missing ones so
everything is ok now.

Thanks. I will check these links.
Post by getyourcontacts (Yang Zhang)
I saw eralng has its own webserver and distribute database. These
Post by getyourcontacts (Yang Zhang)
looks quite good.
But after I wrote some web programs, I found erlang even doesn't have
a strong enough htmlentities or urlencode , urldecode function. What's
the problem here?
Isnot erlang a web language?
htmlentities, urlencode/decode are easy part. Supplied by
any erlang web frameworks.
http://nitrogenproject.com/web/samples/comet2
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/
http://couchdb.apache.org/
http://aws.amazon.com/simpledb/
http://www.onscale.de/scalaris.html
http://www.onscale.de/Schuett_Google_Scalability.pdf
best regards,
taavi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090212/9f76afdb/attachment.html>
erlang (Joe Armstrong)
2009-02-12 15:53:51 UTC
Permalink
Post by getyourcontacts (Yang Zhang)
Thanks all for replying.
Just think erlang's database and distribute feature are so great so it is
the best way I can think to make a distribute crawler and web page
analyzor(what I am doing), then found it doesn't have strong built in web
library like urlencode/htmlentities for me to process url and html. And it
builtin httpclient even ibrowse doesn't support bind IP when initial http
request.
Never mind a function is complex or easy, what in my mind is erlang didn't
have it so it? is incomplete.
But it does - I leave it to you as an exercise in Googling to find
such routines.

I read your initial mail and did a Quick google search and quickly
found *exactly*
what you wanted - at least I think it was what you wanted.

No language serves up library code to you on a plate with no effort involved.
I've recently written a load of javascript - here there is a plethora
of library code
a very quick Google searches reveals what I want.

After a while I found it was better to learn javascript *properly*
than waste time
looking for library functions. Even if you find a library function it
is unlikely that it will do *exactly* what you want - so you have to
read the code
and fix it in any case.

At the end of the day most good programmers end up writing the code they want
because it is *quicker* than searching in vain for library code that
may or may not work and may of may not do what they want. Even if they
find the code they cannot
be sure that it is 100% correct.

This is just life - even if you find library A that has what you want,
library A might
depend upon B. And C which you also want might also might depend upon
B (but perhaps, *a different version of B*) - this happens so often
that after about a year
it becomes completely impossible to recompile the latest version of some code
in your favorite operating system because all the dependencies are buggered up.

The only known way of connecting things in a future proof way is to isolate them
through message passing interfaces with defined protocols.

If you find the fabelled "web language" let us know - I have never seen anything
remotely usable - every single framework and library I have tried is
deeply flawed in one way or another. Some things are easy, other
things hard.

In Erlang making a fault-tolerant fail-over database is not impossibly
difficuly -
writing urldecode might be a pain - but as they say "no pain no gain"

If we take (for example PHP) I imagine writing urldecode is a no-brainer
- but writing a fault-tolerent database with hot standby might just be on the
tricky side.

Have a nice day

/Joe Armstrong
Post by getyourcontacts (Yang Zhang)
No one like to write the simple code again and
it. Glad see it has another library to compensate the missing ones so
everything is ok now.
Thanks. I will check these links.
Post by taavi (Taavi Talvik)
Post by getyourcontacts (Yang Zhang)
I saw eralng has its own webserver and distribute database. These
looks quite good.
But after I wrote some web programs, I found erlang even doesn't have
a strong enough htmlentities or urlencode , urldecode function. What's
the problem here?
Isnot erlang a web language?
htmlentities, urlencode/decode are easy part. Supplied by
any erlang web frameworks.
http://nitrogenproject.com/web/samples/comet2
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/
http://couchdb.apache.org/
http://aws.amazon.com/simpledb/
http://www.onscale.de/scalaris.html
http://www.onscale.de/Schuett_Google_Scalability.pdf
best regards,
taavi
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
kevin (Kevin Scaldeferri)
2009-02-12 17:12:55 UTC
Permalink
Post by erlang (Joe Armstrong)
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.
Post by erlang (Joe Armstrong)
At the end of the day most good programmers end up writing the code they want
because it is *quicker* than searching in vain for library code that
may or may not work and may of may not do what they want. Even if they
find the code they cannot
be sure that it is 100% correct.
Respectfully, I think that's quite untrue. Perhaps there are some
problem domains where it holds, but there are many others where it's
not the case. It would be pure arrogance to think that you are just
going to whip out an XML parser or an implementation of many of the
common internet protocols that is more correct than library code
that's been used by many people over many months or years.


-kevin
mpalmer (Matthew Palmer)
2009-02-12 19:28:32 UTC
Permalink
Post by kevin (Kevin Scaldeferri)
Post by erlang (Joe Armstrong)
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
--
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.
harveyd (Dale Harvey)
2009-02-12 22:03:39 UTC
Permalink
2009/2/12 Matthew Palmer <mpalmer>
Post by mpalmer (Matthew Palmer)
Post by kevin (Kevin Scaldeferri)
Post by erlang (Joe Armstrong)
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.
Post by mpalmer (Matthew Palmer)
--
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
http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090212/efe6f495/attachment.html>
nick (Nick Gerakines)
2009-02-12 22:40:46 UTC
Permalink
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
Post by harveyd (Dale Harvey)
2009/2/12 Matthew Palmer <mpalmer>
Post by mpalmer (Matthew Palmer)
Post by kevin (Kevin Scaldeferri)
Post by erlang (Joe Armstrong)
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.
Post by mpalmer (Matthew Palmer)
--
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
http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
harveyd (Dale Harvey)
2009-02-12 22:50:50 UTC
Permalink
2009/2/12 Nick Gerakines <nick>
Post by nick (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
Post by harveyd (Dale Harvey)
2009/2/12 Matthew Palmer <mpalmer>
Post by mpalmer (Matthew Palmer)
Post by kevin (Kevin Scaldeferri)
Post by erlang (Joe Armstrong)
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
Post by harveyd (Dale Harvey)
Post by mpalmer (Matthew Palmer)
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
Post by harveyd (Dale Harvey)
Post by mpalmer (Matthew Palmer)
in
Erlang and it's surrounding community. I've gotten sick of half-arsed
web
Post by harveyd (Dale Harvey)
Post by mpalmer (Matthew Palmer)
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
Post by harveyd (Dale Harvey)
Post by mpalmer (Matthew Palmer)
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.
Post by mpalmer (Matthew Palmer)
--
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!
Post by harveyd (Dale Harvey)
Post by mpalmer (Matthew Palmer)
Type apt-get moo.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions
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.html>
dmitriid (Dmitrii Dimandt)
2009-02-13 08:23:25 UTC
Permalink
Post by nick (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.
That's exactly what fess was talking about. Had you not mentioned
these projects, no one would ever discover them (well, I would, but I
run a Russian Erlang-related-news site, so I scour the web, blogs and
mailing lists for news and bits and pieces of info)

Erlang should really get a repositroy that is as ubiquitous and as
easy to use as Ruby's gem or Perl's CPAN. Yes, there is a lot of utter
crap in those repositories, but they are valuable for the fact that
you can easily search and instal necessary modules.

For instance, I can name at least three mutually incompatible JSON
encoding/decoding libraries written for erlang (there are at least 5,
I think). Definitely at least two libraries dealing with utf-8. Two
OpenID projects. Two dedicated wrappers for traditional RDBMs (and a
third, which is a more general ORM-style library). At least three (I
think) projects that connect to Amazon's web services in one way or
another. Two projects interfacing with memcached. And the list *will*
grow. These are just projects I can name off the top of my head

"Let a hundred flowers blossom" (c) Mao Zedong

Quite often I don't think that authors of some of these project even
now that similar projects exist. Forget the users, they will *never*
even discover some of them :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090213/9c83c802/attachment.html>
nick (Nick Gerakines)
2009-02-13 08:46:43 UTC
Permalink
Post by nick (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.
That's exactly what fess was talking about. Had you not mentioned these
projects, no one would ever discover them (well, I would, but I run a
Russian Erlang-related-news site, so I scour the web, blogs and mailing
lists for news and bits and pieces of info)
Erlang should really get a repositroy that is as ubiquitous and as easy to
use as Ruby's gem or Perl's CPAN. Yes, there is a lot of utter crap in those
repositories, but they are valuable for the fact that you can easily search
and instal necessary modules.
For instance, I can name at least three mutually incompatible JSON
encoding/decoding libraries written for erlang (there are at least 5, I
think). Definitely at least two libraries dealing with utf-8. Two OpenID
projects. Two dedicated wrappers for traditional RDBMs (and a third, which
is a more general ORM-style library). At least three (I think) projects that
connect to Amazon's web services in one way or another. Two projects
interfacing with memcached. And the list *will* grow. These are just
projects I can name off the top of my head
"Let a hundred flowers blossom" (c) Mao Zedong
Quite often I don't think that authors of some of these project even now
that similar projects exist. Forget the users, they will *never* even
discover some of them :)
I agree with what you are getting at. I would love it if there was
some sort of standard packaging and installation system for Erlang. A
gem equivalent or Module::Build, if you will. But there really isn't.
At EA we've been using your standard `make`, `make test` and `make
install` targets which works for what we want and is rpm/ebuild/deb
friendly.

I've been watching GitHub really grow with Erlang projects lately.
That is where we put all of ours as well.

# Nick Gerakines
dmitriid (Dmitrii Dimandt)
2009-02-13 10:15:49 UTC
Permalink
Post by nick (Nick Gerakines)
I've been watching GitHub really grow with Erlang projects lately.
That is where we put all of ours as well.
# Nick Gerakines
Yeah :) It should really be renamed into Erlangforge :)
kunthar (Kunthar)
2009-02-13 11:42:09 UTC
Permalink
I wish that all those fellas could combine efforts to bring one big
hub for erlang;

http://www.erlware.org/
http://cean.process-one.net/packages/index.yaws?action=all
http://www.trapexit.org/Special:UserContributions
(I would miss some more)

I like FreeBSD way. If a project should be examined as located in
monolithic structure, should be elected by main developers.
If a project located in userland then users can submit to central repo
to show their work to others.
There should be a consensus about package usage, distribution and
installation issues.
I love git but it doesn't give me cean:display(installed) happiness. I
do not want to waste my time to find
a package for a one work. OTOH, world is parallel and each parallel
worlds there are way too many details.
I don't have to deal with all aspects of those bloody details. If i
need a logger, fine then, can borrow from one
fellow erlanger and use it. Sure that i can produce my own code and
throw out for community too.

If someone started to use Erlang, it means, they already smart enough,
isn't it :-)

Peace
Kunthar
Post by dmitriid (Dmitrii Dimandt)
Post by nick (Nick Gerakines)
I've been watching GitHub really grow with Erlang projects lately.
That is where we put all of ours as well.
# Nick Gerakines
Yeah :) It should really be renamed into Erlangforge :)
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
kaczmarek.w (Wojciech Kaczmarek)
2009-02-14 17:25:40 UTC
Permalink
Post by nick (Nick Gerakines)
I agree with what you are getting at. I would love it if there was
some sort of standard packaging and installation system for Erlang. A
gem equivalent or Module::Build, if you will. But there really isn't.
At EA we've been using your standard `make`, `make test` and `make
install` targets which works for what we want and is rpm/ebuild/deb
friendly.
Good point. Popular, portable and enjoyable method of packaging is one
thing, and central repository of those is another. Ruby gems or CPAN have
them both. I guess the former is most important. Having it you can still
choose where to pick it from (think quality). This way we could improve the
process of building 3rd party stuff and of distributing our own stuff,
commercial or open, whatever. 'Where to get the stuff' is just another
problem and we are not forced to join those two domains together.

Compare to python, when setup.py -- really cool method of bundling your
package -- existed years before python eggs (gem-like solution).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090214/227bebf3/attachment.html>
kaczmarek.w (Wojciech Kaczmarek)
2009-02-14 17:10:29 UTC
Permalink
2009/2/13 Dmitrii Dimandt <dmitriid>
Post by nick (Nick Gerakines)
That's exactly what fess was talking about. Had you not mentioned these
projects, no one would ever discover them (well, I would, but I run a
Russian Erlang-related-news site, so I scour the web, blogs and mailing
lists for news and bits and pieces of info)
Erlang should really get a repositroy that is as ubiquitous and as easy to
use as Ruby's gem or Perl's CPAN. Yes, there is a lot of utter crap in those
repositories, but they are valuable for the fact that you can easily search
and instal necessary modules.
For instance, I can name at least three mutually incompatible JSON
encoding/decoding libraries written for erlang (there are at least 5, I
think). Definitely at least two libraries dealing with utf-8. Two OpenID
projects. Two dedicated wrappers for traditional RDBMs (and a third, which
is a more general ORM-style library). At least three (I think) projects that
connect to Amazon's web services in one way or another. Two projects
interfacing with memcached. And the list *will* grow. These are just
projects I can name off the top of my head
"Let a hundred flowers blossom" (c) Mao Zedong
Quite often I don't think that authors of some of these project even now
that similar projects exist. Forget the users, they will *never* even
discover some of them :)
Hello,
3 cents from a perspective of someone who did a lot of searching of quality
3rd-party Erlang software during last two years, for the purposes of r&d
first and later for the production use in a startup.

Centralized repository is tempting (I missed it at the beginning), but it
also requires lots of Q&A work. It can be obvious for anybody who
participated in maintaining some Linux of *BSD distribution. Also it can
reveal specific social incompatibilies between users, as they needs vary
more than most of people would like to admit. And it's not very good for the
perception of the community to start a centralized service which will fail
later.

The simpler step is to make searching easier. A website aggregating some
automatically-retrieved info (from googlecode, github, sourceforge) with a
human-entered content (by those authors who'd like to care about it) comes
to mind. The results could be sorted somehow, with a raw google search
output as a last resort. Something like that could be plugged into Planet
Erlang.

There's no silver bullet when it comes to managing external software. In
production you usually want to stick with carefully chosen and often patched
specific versions of 3rd party stuff, otherwise you easily introduce a new
point of failure and make the release management pain in the ass. I'm very
happy that Erlang is the first language making a sane conenction between
HA-world, where you think about your production environment in a very
specific way, and the usual "opensource libraries for all, let's grab it"
approach.

cheers,

-- Wojtek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090214/cc3fa51e/attachment.html>
harveyd (Dale Harvey)
2009-02-14 17:38:08 UTC
Permalink
2009/2/14 Wojciech Kaczmarek <kaczmarek.w>
Post by kaczmarek.w (Wojciech Kaczmarek)
2009/2/13 Dmitrii Dimandt <dmitriid>
Post by nick (Nick Gerakines)
That's exactly what fess was talking about. Had you not mentioned these
projects, no one would ever discover them (well, I would, but I run a
Russian Erlang-related-news site, so I scour the web, blogs and mailing
lists for news and bits and pieces of info)
Erlang should really get a repositroy that is as ubiquitous and as easy to
use as Ruby's gem or Perl's CPAN. Yes, there is a lot of utter crap in those
repositories, but they are valuable for the fact that you can easily search
and instal necessary modules.
For instance, I can name at least three mutually incompatible JSON
encoding/decoding libraries written for erlang (there are at least 5, I
think). Definitely at least two libraries dealing with utf-8. Two OpenID
projects. Two dedicated wrappers for traditional RDBMs (and a third, which
is a more general ORM-style library). At least three (I think) projects that
connect to Amazon's web services in one way or another. Two projects
interfacing with memcached. And the list *will* grow. These are just
projects I can name off the top of my head
"Let a hundred flowers blossom" (c) Mao Zedong
Quite often I don't think that authors of some of these project even now
that similar projects exist. Forget the users, they will *never* even
discover some of them :)
Hello,
3 cents from a perspective of someone who did a lot of searching of quality
3rd-party Erlang software during last two years, for the purposes of r&d
first and later for the production use in a startup.
Centralized repository is tempting (I missed it at the beginning), but it
also requires lots of Q&A work. It can be obvious for anybody who
participated in maintaining some Linux of *BSD distribution. Also it can
reveal specific social incompatibilies between users, as they needs vary
more than most of people would like to admit. And it's not very good for the
perception of the community to start a centralized service which will fail
later.
The simpler step is to make searching easier. A website aggregating some
automatically-retrieved info (from googlecode, github, sourceforge) with a
human-entered content (by those authors who'd like to care about it) comes
to mind. The results could be sorted somehow, with a raw google search
output as a last resort. Something like that could be plugged into Planet
Erlang.
There's no silver bullet when it comes to managing external software. In
production you usually want to stick with carefully chosen and often patched
specific versions of 3rd party stuff, otherwise you easily introduce a new
point of failure and make the release management pain in the ass. I'm very
happy that Erlang is the first language making a sane conenction between
HA-world, where you think about your production environment in a very
specific way, and the usual "opensource libraries for all, let's grab it"
approach.
I registered erldocs.com with the intention of doing pretty much exactly
that. right now I am waiting on the ability to fully generate the erlang
documentation from source, then I was planning to improve usability /
searchability, then on importing documentation of open source 3rd party libs

however I am a bit torn because http://erlware.org/documentation/index.html
does a large amount of what I was planning to do, the frontend could be
improved quite a lot, but its a good start.

So i think it comes down to, why arent people using faxien / sinan?, I tried
them
out a while ago and had some teething issues, however they seem to
stabilising
recently, I am going to give it a bit more of a thorough look and try
packaging
some applications for it. are there any core reasons why people dont use it,
or
was it purely a maturity issue.

(just to note, it isnt a centralised repository, you can setup your own
public
and private repos)
Post by kaczmarek.w (Wojciech Kaczmarek)
cheers,
-- Wojtek
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090214/978be37c/attachment.html>
erlang-questions_efine (Edwin Fine)
2009-02-14 19:30:11 UTC
Permalink
2009/2/14 Dale Harvey <harveyd>
Post by harveyd (Dale Harvey)
2009/2/14 Wojciech Kaczmarek <kaczmarek.w>
2009/2/13 Dmitrii Dimandt <dmitriid>
Post by kaczmarek.w (Wojciech Kaczmarek)
Post by nick (Nick Gerakines)
That's exactly what fess was talking about. Had you not mentioned these
projects, no one would ever discover them (well, I would, but I run a
Russian Erlang-related-news site, so I scour the web, blogs and mailing
lists for news and bits and pieces of info)
Erlang should really get a repositroy that is as ubiquitous and as easy
to use as Ruby's gem or Perl's CPAN. Yes, there is a lot of utter crap in
those repositories, but they are valuable for the fact that you can easily
search and instal necessary modules.
For instance, I can name at least three mutually incompatible JSON
encoding/decoding libraries written for erlang (there are at least 5, I
think). Definitely at least two libraries dealing with utf-8. Two OpenID
projects. Two dedicated wrappers for traditional RDBMs (and a third, which
is a more general ORM-style library). At least three (I think) projects that
connect to Amazon's web services in one way or another. Two projects
interfacing with memcached. And the list *will* grow. These are just
projects I can name off the top of my head
"Let a hundred flowers blossom" (c) Mao Zedong
Quite often I don't think that authors of some of these project even now
that similar projects exist. Forget the users, they will *never* even
discover some of them :)
Hello,
3 cents from a perspective of someone who did a lot of searching of
quality 3rd-party Erlang software during last two years, for the purposes of
r&d first and later for the production use in a startup.
Centralized repository is tempting (I missed it at the beginning), but it
also requires lots of Q&A work. It can be obvious for anybody who
participated in maintaining some Linux of *BSD distribution. Also it can
reveal specific social incompatibilies between users, as they needs vary
more than most of people would like to admit. And it's not very good for the
perception of the community to start a centralized service which will fail
later.
The simpler step is to make searching easier. A website aggregating some
automatically-retrieved info (from googlecode, github, sourceforge) with a
human-entered content (by those authors who'd like to care about it) comes
to mind. The results could be sorted somehow, with a raw google search
output as a last resort. Something like that could be plugged into Planet
Erlang.
There's no silver bullet when it comes to managing external software. In
production you usually want to stick with carefully chosen and often patched
specific versions of 3rd party stuff, otherwise you easily introduce a new
point of failure and make the release management pain in the ass. I'm very
happy that Erlang is the first language making a sane conenction between
HA-world, where you think about your production environment in a very
specific way, and the usual "opensource libraries for all, let's grab it"
approach.
I registered erldocs.com with the intention of doing pretty much exactly
that. right now I am waiting on the ability to fully generate the erlang
documentation from source, then I was planning to improve usability /
searchability, then on importing documentation of open source 3rd party libs
however I am a bit torn because
http://erlware.org/documentation/index.html
does a large amount of what I was planning to do, the frontend could be
improved quite a lot, but its a good start.
So i think it comes down to, why arent people using faxien / sinan?, I
tried them
out a while ago and had some teething issues, however they seem to
stabilising
recently, I am going to give it a bit more of a thorough look and try
packaging
some applications for it. are there any core reasons why people dont use
it, or
was it purely a maturity issue.
I am using sinan/faxien exclusively, and have installed and maintained four
Erlang production systems with them. There were some teething issues, some
of which were very annoying to the point that some people stopped using the
software, but I soldiered on and the software is improving. Even with the
bugs and problems, it's a while lot better than the make-based solution I
was using before. I really hope that Faxien and Sinan make it because they
are closer to what I want in a build/distribution system for Erlang than
anything else I have used, even with their current limitations. I wish the
whole OTP was distributed like this.
Post by harveyd (Dale Harvey)
(just to note, it isnt a centralised repository, you can setup your own
public
and private repos)
Post by kaczmarek.w (Wojciech Kaczmarek)
cheers,
-- Wojtek
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090214/da0ac886/attachment.html>
erlang-questions_efine (Edwin Fine)
2009-02-14 19:31:18 UTC
Permalink
Post by erlang-questions_efine (Edwin Fine)
it's a while lot better
I meant a "whole lot better".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090214/4006f02f/attachment.html>
kevin (Kevin Scaldeferri)
2009-02-12 22:26:58 UTC
Permalink
Post by mpalmer (Matthew Palmer)
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.
That's great, and I wish you luck, but once you're done it would be
nice if you share some of that awesome code with the rest of us, so
everyone doesn't have to be burdened to write their own perfect code
for everything they do.


-kevin
toby (Toby Thain)
2009-02-14 18:56:51 UTC
Permalink
Post by kevin (Kevin Scaldeferri)
Post by mpalmer (Matthew Palmer)
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.
That's great, and I wish you luck, but once you're done it would be
nice if you share some of that awesome code with the rest of us, so
everyone doesn't have to be burdened to write their own perfect code
for everything they do.
TOUCH?!

--Toby
Post by kevin (Kevin Scaldeferri)
-kevin
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
dave.smith.to (Dave Smith)
2009-02-12 22:39:41 UTC
Permalink
I generally agree with Joe and Valentin. I'm not saying I'd write my own
XML parser; I try to avoid XML altogether if I can.

How many time have I come across programmers using more code to glue a
square peg in a round hole than it would take to construct the round peg in
the first place.


--DS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090212/eb27673f/attachment.html>
steven.charles.davis (Steve Davis)
2009-02-13 07:06:11 UTC
Permalink
Dave, I respectfully offer you my "Joe sez: XML is for Docs not Apps!"
t-shirt (tm), as I think you will appreciate it :)

Good to see common sense making an ever more vocal comeback!
Post by dave.smith.to (Dave Smith)
I try to avoid XML altogether if I can.
kevin (Kevin Scaldeferri)
2009-02-13 15:45:21 UTC
Permalink
When I mentioned XML parsers as an example of something you do not
want to write yourself, I didn't intend for anyone to think I was
suggesting using XML for internal data storage. So, if you never have
to worry about document exchange with an external party in an XML
format, consider yourself fortunate and pass over that example. The
sort of work I do often involves this requirement, though, and
virtually every time the other party has decided to use some
"interesting" corner of the XML spec, and I'm thankful someone else
already wrote the library to handle it.

-kevin
Post by steven.charles.davis (Steve Davis)
Dave, I respectfully offer you my "Joe sez: XML is for Docs not Apps!"
t-shirt (tm), as I think you will appreciate it :)
Good to see common sense making an ever more vocal comeback!
Post by dave.smith.to (Dave Smith)
I try to avoid XML altogether if I can.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
toby (Toby Thain)
2009-02-14 18:51:27 UTC
Permalink
Post by kevin (Kevin Scaldeferri)
Post by erlang (Joe Armstrong)
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;
Or arguably Java - where the libraries are indeed delivered on a
plate, and are generally very high quality.

--Toby
Post by kevin (Kevin Scaldeferri)
with
Ruby and, increasingly, Haskell making good showings). A good
repository of reusable code is a huge boon to a language.
Post by erlang (Joe Armstrong)
At the end of the day most good programmers end up writing the code they want
because it is *quicker* than searching in vain for library code that
may or may not work and may of may not do what they want. Even if they
find the code they cannot
be sure that it is 100% correct.
Respectfully, I think that's quite untrue. Perhaps there are some
problem domains where it holds, but there are many others where it's
not the case. It would be pure arrogance to think that you are just
going to whip out an XML parser or an implementation of many of the
common internet protocols that is more correct than library code
that's been used by many people over many months or years.
-kevin
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
v (Valentin Micic)
2009-02-12 17:51:02 UTC
Permalink
Post by kevin (Kevin Scaldeferri)
It would be pure arrogance to think that you are just
going to whip out an XML parser
[...]
Post by kevin (Kevin Scaldeferri)
library code that's been used by many people over
many months or years.
Arrogance or not, it is usually much easier to write "your own" than to try
to fit a square through a round hole.

As for "used by many people..." assertion, IMO, the "safety in numbers" is a
fool's paradise when it comes to programming. There are far more projects
that fail than one that are successful, and of these that are "successful",
even fewer deliver to expectations. A logical destination of such reasoning
would be that you're more likely to fail if you do what everybody else is
doing. So, stop pushing this square trough a triangular hole and start using
your imagination. As No.44 would say -- with Erlang, you can!

V.
fess-erlang (fess)
2009-02-12 18:30:52 UTC
Permalink
Post by v (Valentin Micic)
Post by kevin (Kevin Scaldeferri)
It would be pure arrogance to think that you are just
going to whip out an XML parser
[...]
Post by kevin (Kevin Scaldeferri)
library code that's been used by many people over
many months or years.
Arrogance or not, it is usually much easier to write "your own" than to try
to fit a square through a round hole.
As for "used by many people..." assertion, IMO, the "safety in
numbers" is a
fool's paradise when it comes to programming. There are far more projects
that fail than one that are successful, and of these that are
"successful",
even fewer deliver to expectations. A logical destination of such reasoning
would be that you're more likely to fail if you do what everybody else is
doing. So, stop pushing this square trough a triangular hole and start using
your imagination. As No.44 would say -- with Erlang, you can!
Wow,
Joe's post disappointed me.
Valentin's post has inflamed me.

I have to back kevin up here.

To use Valintin's metaphor:
There are times when it is easier to fit the round peg of the correct
diameter
provided by the public library tested and used by people all solving
the same common
sub problem of their larger problem. much easier than carving out your
own peg which turns out to be not quite so round and doesn't quite fit
right
but sort of gets the job done and wasted a lot of your time which should
have been spent on the part of the your problem where your innovation
was actually required.

It is an arrogant fools paradise to think that every part of your
problem is so
unique that you can do it better than all those who collaborated
before you,
or that it is even worth your time to do so.


A logical destination of such reasoning would be that we should each
individually
rewrite erlang because to quote joe:

"At the end of the day most good programmers end up writing the code
they want
because it is *quicker* than searching in vain for library code that
may or may not work and may of may not do what they want. Even if they
find the code they cannot be sure that it is 100% correct."

IMO a seemingly hostile attitude toward improving libraries
and availability of libraries is bad for everybody.

We all stand on the backs of Giants, those who don't believe so
should spend their days rewriting kernels, perhaps we'll stand
on their backs some day but if we all did it, well, we wouldn't
be very tall giants.

I hope this email is not too inflamatory, and I apologize because it
probably is,
but there's something going on here that really worries me about erlang.

--fess
so, sad that he took the fall into this thread.
I hope that ulf says something sage to make it all better. *grin*


















--fess
v (Valentin Micic)
2009-02-12 19:21:50 UTC
Permalink
Post by fess-erlang (fess)
Valentin's post has inflamed me.
I can see that. Not sure why, but so be it.

V.
toby (Toby Thain)
2009-02-14 18:55:44 UTC
Permalink
Post by v (Valentin Micic)
Post by fess-erlang (fess)
Valentin's post has inflamed me.
I can see that. Not sure why, but so be it.
Because there are some serious problems created by constant
reinvention of the wheel.

1) enormous wasted effort (good libraries are expensive to write!)
2) typically worse result (not every programmer is a genius)
3) much higher maintenance cost due to inflated codebase and
ignorance of established standards (i.e. methods and tools that other
people might already have skills in).
4) others, no doubt.

But the only argument in your favour is, "I think I can do a better
job than anyone else". Perhaps that's true of you, but it's not true
of 99.9% of programmers. - And nor does that 99.9% have the time and
energy to expend rewriting existing libraries. Without clear
justification, I'd consider it a serious misdemeanor in a workplace.

--Toby
Post by v (Valentin Micic)
V.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
watson.timothy (Tim Watson)
2009-02-15 02:29:28 UTC
Permalink
Post by erlang-questions_efine (Edwin Fine)
I am using sinan/faxien exclusively, and have installed and maintained four
Erlang production systems with them. There were some teething issues, some
This is interesting - I also started out with good feelings about
sinan/faxien, but they appear to redistribute the core OTP libraries
which is anathema where I work. We're simply not allowed (by law) to
run code on "some version" of kernel/stdlib/etc that didn't come from
a verified (official) sources, even if it did in reality (if you see
what I mean). This is an issue of regulatory compliance, so we're
stuck and can't use the tools, which are (I agree) very nice bar some
minor usability issues. I suspect this puts a lot of people off - it's
not as maven downloads and installs the JDK for you is it, and for
good reason - I'd be surprised if that many people actually wanted
this.

Clearly there are mixed opinions about whether a repository for
publishing applications and a distributed build system that can
consume code from public/private repos, is a good approach. That's to
be expected, but this idea of redistributing "Erlang itself" is
another thing altogether. It seems like trying to force too many new
ideas at once, and I suspect this is a big part of the problem.
erlang-questions_efine (Edwin Fine)
2009-02-15 03:31:05 UTC
Permalink
Post by watson.timothy (Tim Watson)
Post by erlang-questions_efine (Edwin Fine)
I am using sinan/faxien exclusively, and have installed and maintained
four
Post by erlang-questions_efine (Edwin Fine)
Erlang production systems with them. There were some teething issues,
some
This is interesting - I also started out with good feelings about
sinan/faxien, but they appear to redistribute the core OTP libraries
which is anathema where I work.
Martin & Eric can speak for themselves, but my point of view is that, well,
they don't really redistribute them *as such*. They are forced to build them
using their own tools and put them in their WebDAV repository because (a)
The OTP team doesn't support such a repository, and (b) they have to make
minor tweaks to the add their metadata, which is necessary for the
distribution mechanism. The metadata doesn't exist - or, in the case of .app
files, sometimes doesn't quite fit in - in the OTP distribution. I am pretty
(99%) sure there is no fiddling with the source code at all, it's just an
alternative way to build it, no more suspicious than building OTP from the
tarball. If there was a way to build OTP with their (Erlware) tools in a
100% automated way, then anyone could do it, but they are not quite there
yet (as far as I know). So that is indeed a sticking point, I can see.

We're simply not allowed (by law) to
Post by watson.timothy (Tim Watson)
run code on "some version" of kernel/stdlib/etc that didn't come from
a verified (official) sources, even if it did in reality (if you see
what I mean). This is an issue of regulatory compliance, so we're
stuck and can't use the tools, which are (I agree) very nice bar some
minor usability issues. I suspect this puts a lot of people off - it's
not as maven downloads and installs the JDK for you is it, and for
good reason - I'd be surprised if that many people actually wanted
this.
Clearly there are mixed opinions about whether a repository for
publishing applications and a distributed build system that can
consume code from public/private repos, is a good approach. That's to
be expected, but this idea of redistributing "Erlang itself" is
another thing altogether. It seems like trying to force too many new
ideas at once, and I suspect this is a big part of the problem.
Again, I believe they don't WANT to redistribute Erlang. It's a huge pain in
the butt to have to tweak new Erlang releases to build with their toolset,
and it's not really the fault of their toolset, it's just minor
inconsistencies here and there that cause issues. If they could get it right
that anyone could build Erlang itself using Sinan, and then put it in their
own private Erlware repo with Faxien, these objections would largely go
away.

If you look at what Ruby has managed to achieve with Gems, and (I think)
Python with "eggs", it is quite reasonable to expect that we should be able
to distribute our own Erlang apps in a pre-built form in a way that makes it
really easy to update. I use this mechanism to update production servers in
a number of different countries, and the previous way I did it was just
horrible. It's so much easier for me just to log into the remote server,
type in "faxien upgrade-release myapp", maybe tweak the sys.config, and then
restart the application (I don't need hot code update yet). The sad thing is
that Erlware is *so* close to being really great, and is held back mostly
because the authors are so busy actually earning a living that they don't
have enough time to devote to ironing out the wrinkles.

My great hope is that the Erlang/OTP team will see enough merit in this
approach to make this a standard distribution mechanism, but I don't hold
out much hope (not because the team is unreasonable or anything, but because
of the overhead of supporting builds across many hardware platforms and
version within the platforms.) An easier and even better thing would be if
they actually used Erlware to build the Erlang source code; then we could
all build it with Erlware and the main objection would be solved. Also, they
could put some resources on it to help with the wrinkles.

Just dreaming ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090214/38e04765/attachment.html>
erlang (Joe Armstrong)
2009-02-15 11:56:19 UTC
Permalink
This is my take on the matter.

To start with I don't think one distribution scheme or library will
ever work - the work
making it consistent is colossal.

I rather like what's happened in the javascript world.

Here there is a core-language, and alternative sets of rather-good libraries.

To me a good library has

- a book (or books) -
- community who contribute to the library
- a unifying principle
- a set of applications that use the library

The javascript jquery and protoype libraries live up these criteria.

After I finished the erlang book I started writing a library and a number of
applications based on the library. My plan is:

a) write a base library and applications
b) open source it and invite community participial
c) improve quality of library through participation
d) write a book describing the library

I'm in the middle of a) - I now have a dilemma, should I release now or later.

advantages: early feedback
disadvantages: quality problems - it's in a bit of a mess, so it gets
a bad reputation.

Or wait a year or so:

advantages: higher quality of release
disadvantage: loose user feedback

Do you want software "early and buggy, badly documented" or
"late and better documented, higher quality"

I would welcome some feedback here

/Joe Armstrong
On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <watson.timothy>
Post by watson.timothy (Tim Watson)
Post by erlang-questions_efine (Edwin Fine)
I am using sinan/faxien exclusively, and have installed and maintained four
Erlang production systems with them. There were some teething issues, some
This is interesting - I also started out with good feelings about
sinan/faxien, but they appear to redistribute the core OTP libraries
which is anathema where I work.
Martin & Eric can speak for themselves, but my point of view is that, well,
they don't really redistribute them as such. They are forced to build them
using their own tools and put them in their WebDAV repository because (a)
The OTP team doesn't support such a repository, and (b) they have to make
minor tweaks to the add their metadata, which is necessary for the
distribution mechanism. The metadata doesn't exist - or, in the case of .app
files, sometimes doesn't quite fit in - in the OTP distribution. I am pretty
(99%) sure there is no fiddling with the source code at all, it's just an
alternative way to build it, no more suspicious than building OTP from the
tarball. If there was a way to build OTP with their (Erlware) tools in a
100% automated way, then anyone could do it, but they are not quite there
yet (as far as I know). So that is indeed a sticking point, I can see.
Post by watson.timothy (Tim Watson)
We're simply not allowed (by law) to
run code on "some version" of kernel/stdlib/etc that didn't come from
a verified (official) sources, even if it did in reality (if you see
what I mean). This is an issue of regulatory compliance, so we're
stuck and can't use the tools, which are (I agree) very nice bar some
minor usability issues. I suspect this puts a lot of people off - it's
not as maven downloads and installs the JDK for you is it, and for
good reason - I'd be surprised if that many people actually wanted
this.
Clearly there are mixed opinions about whether a repository for
publishing applications and a distributed build system that can
consume code from public/private repos, is a good approach. That's to
be expected, but this idea of redistributing "Erlang itself" is
another thing altogether. It seems like trying to force too many new
ideas at once, and I suspect this is a big part of the problem.
Again, I believe they don't WANT to redistribute Erlang. It's a huge pain in
the butt to have to tweak new Erlang releases to build with their toolset,
and it's not really the fault of their toolset, it's just minor
inconsistencies here and there that cause issues. If they could get it right
that anyone could build Erlang itself using Sinan, and then put it in their
own private Erlware repo with Faxien, these objections would largely go
away.
If you look at what Ruby has managed to achieve with Gems, and (I think)
Python with "eggs", it is quite reasonable to expect that we should be able
to distribute our own Erlang apps in a pre-built form in a way that makes it
really easy to update. I use this mechanism to update production servers in
a number of different countries, and the previous way I did it was just
horrible. It's so much easier for me just to log into the remote server,
type in "faxien upgrade-release myapp", maybe tweak the sys.config, and then
restart the application (I don't need hot code update yet). The sad thing is
that Erlware is *so* close to being really great, and is held back mostly
because the authors are so busy actually earning a living that they don't
have enough time to devote to ironing out the wrinkles.
My great hope is that the Erlang/OTP team will see enough merit in this
approach to make this a standard distribution mechanism, but I don't hold
out much hope (not because the team is unreasonable or anything, but because
of the overhead of supporting builds across many hardware platforms and
version within the platforms.) An easier and even better thing would be if
they actually used Erlware to build the Erlang source code; then we could
all build it with Erlware and the main objection would be solved. Also, they
could put some resources on it to help with the wrinkles.
Just dreaming ;)
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
watson.timothy (Tim Watson)
2009-02-15 12:28:02 UTC
Permalink
Hi all,

Robert, I work at British Telecommunications. As the former state run
monopoly, we are subject to a great deal of regulation. There's also a
fair degree of paranoia about having safe and reliable code. Open
source is a relatively new thing at BT and there's an understandable
(and IMHO reasonable) desire to make sure that it comes from a
verifiable and reliable source.

Joe, I tend to agree that there isn't a single approach that works for
everyone - even if you've chosen maven (which is ubiquitous in the
java world) there are some jars that aren't in a repo and need to be
manually added to your corporate repo/mirror server. As for the issue
of when to release, I really want both. I like to know that a project
is available, but I tend not to depend on projects that are still in
alpha. I probably wont use an immature library which is poorly
documented, but I might get involved in developing it if it offers
functionality I need and is quite well underway. This aids with
discovery and I don't tend to judge alpha releases on
bugs/documentation anyway - I just don't use them. If it's alpha then
it's not meant for production and any poor reputation is quite
undeserved. I appreciate the conundrum though, as not everyone thinks
this way.

Edwin, I take your point about this being something Erlware is stuck
with, but it's only because of design decisions really. The
"mechanism" by which libs in the $ERL_TOP/lib folder are versioned
appears to be a naming convention, so locating stdlib shouldn't be
that hard. In addition to this, running one version of stdlib
alongside another version of kernel is madness (because the Erlang
team won't have tested this combination) so I don't think Erlware
should be distributing these libraries at all. I don't understand why
they're forced to, in order to distribute and build 3rd party
packages. Maven does not put the JDK libraries in the repository. I
don't get hold of the ruby 'stdlib' using the rubygems mechanism, it
comes bundled with the distribution. You don't go to the cheeseshop to
get hold of eggs for the 'os' or 'sys' modules, they just come with
python. This is a design decision, not a technical constraint. If this
were not the case (or if it was configurable), then I'd happily invest
my time in helping with Erlware instead of working on our custom build
system.

Our build system does everything locally (build, test, doc, generate
boot scripts based on content of the .app file, generate shell scripts
for starting the app in priv/scripts, OTP package/tar, push to repo -
appup/relup is still somewhat manual but we generate scripts to do it)
and doesn't require any custom meta-data whatsoever. Our distribution
mechanism is to generate install scripts alongside the app tarball,
then put these into generated debian packages and push them into apt
repositories.

This is very much non-standard (unless you're company is standardised
on debian - which we're not!) and so there are two reasons we didn't
open source it. Firstly, when I asked "is it ok to make this public",
I never got a reply. Secondly, I just assumed that the Erlware would
be less environment specific - I was correct - and that everyone would
use it - looks like this might not be the case. Decoupling our choice
of repository is fairly simple, but it means we have no distribution
mechanism at all (apart from nfs, which is where we started :-) None
of the code relies on a specific format of repository, as in reality
it is just a bit of glue around command line programs (erl, erlc,
apt-get, etc).
peter (Peter Sabaini)
2009-02-15 12:30:32 UTC
Permalink
Post by erlang (Joe Armstrong)
This is my take on the matter.
To start with I don't think one distribution scheme or library will
ever work - the work
making it consistent is colossal.
Yet rubygems or PyPI seem to work out quite well.

To me this is mostly about findability and having a uniform interface for meta
data -- version numbers, homepage, release history etc., this makes a huge
difference in choosing a lib.
Post by erlang (Joe Armstrong)
I rather like what's happened in the javascript world.
Here there is a core-language, and alternative sets of rather-good libraries.
To me a good library has
- a book (or books) -
- community who contribute to the library
- a unifying principle
- a set of applications that use the library
IMHO this rather depends on the library -- a small library that does one thing
well and has only a small interface won't need a whole book for documentation.
Post by erlang (Joe Armstrong)
The javascript jquery and protoype libraries live up these criteria.
After I finished the erlang book I started writing a library and a number
a) write a base library and applications
b) open source it and invite community participial
c) improve quality of library through participation
d) write a book describing the library
I'm in the middle of a) - I now have a dilemma, should I release now or later.
advantages: early feedback
disadvantages: quality problems - it's in a bit of a mess, so it gets
a bad reputation.
advantages: higher quality of release
disadvantage: loose user feedback
Do you want software "early and buggy, badly documented" or
"late and better documented, higher quality"
The classical "Release Early, Release Often" is still a valid approach I
think. As long as it clearly says on the box (with big bold letters) if
something is alpha/beta/release quality you won't get a bad reputation. Or
only from people who do not read :-)

Just my 0.02eurocent...

peter.
Post by erlang (Joe Armstrong)
I would welcome some feedback here
/Joe Armstrong
On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <watson.timothy>
Post by watson.timothy (Tim Watson)
Post by erlang-questions_efine (Edwin Fine)
I am using sinan/faxien exclusively, and have installed and maintained four
Erlang production systems with them. There were some teething issues, some
This is interesting - I also started out with good feelings about
sinan/faxien, but they appear to redistribute the core OTP libraries
which is anathema where I work.
Martin & Eric can speak for themselves, but my point of view is that,
well, they don't really redistribute them as such. They are forced to
build them using their own tools and put them in their WebDAV repository
because (a) The OTP team doesn't support such a repository, and (b) they
have to make minor tweaks to the add their metadata, which is necessary
for the distribution mechanism. The metadata doesn't exist - or, in the
case of .app files, sometimes doesn't quite fit in - in the OTP
distribution. I am pretty (99%) sure there is no fiddling with the source
code at all, it's just an alternative way to build it, no more suspicious
than building OTP from the tarball. If there was a way to build OTP with
their (Erlware) tools in a 100% automated way, then anyone could do it,
but they are not quite there yet (as far as I know). So that is indeed a
sticking point, I can see.
Post by watson.timothy (Tim Watson)
We're simply not allowed (by law) to
run code on "some version" of kernel/stdlib/etc that didn't come from
a verified (official) sources, even if it did in reality (if you see
what I mean). This is an issue of regulatory compliance, so we're
stuck and can't use the tools, which are (I agree) very nice bar some
minor usability issues. I suspect this puts a lot of people off - it's
not as maven downloads and installs the JDK for you is it, and for
good reason - I'd be surprised if that many people actually wanted
this.
Clearly there are mixed opinions about whether a repository for
publishing applications and a distributed build system that can
consume code from public/private repos, is a good approach. That's to
be expected, but this idea of redistributing "Erlang itself" is
another thing altogether. It seems like trying to force too many new
ideas at once, and I suspect this is a big part of the problem.
Again, I believe they don't WANT to redistribute Erlang. It's a huge pain
in the butt to have to tweak new Erlang releases to build with their
toolset, and it's not really the fault of their toolset, it's just minor
inconsistencies here and there that cause issues. If they could get it
right that anyone could build Erlang itself using Sinan, and then put it
in their own private Erlware repo with Faxien, these objections would
largely go away.
If you look at what Ruby has managed to achieve with Gems, and (I think)
Python with "eggs", it is quite reasonable to expect that we should be
able to distribute our own Erlang apps in a pre-built form in a way that
makes it really easy to update. I use this mechanism to update production
servers in a number of different countries, and the previous way I did it
was just horrible. It's so much easier for me just to log into the remote
server, type in "faxien upgrade-release myapp", maybe tweak the
sys.config, and then restart the application (I don't need hot code
update yet). The sad thing is that Erlware is *so* close to being really
great, and is held back mostly because the authors are so busy actually
earning a living that they don't have enough time to devote to ironing
out the wrinkles.
My great hope is that the Erlang/OTP team will see enough merit in this
approach to make this a standard distribution mechanism, but I don't hold
out much hope (not because the team is unreasonable or anything, but
because of the overhead of supporting builds across many hardware
platforms and version within the platforms.) An easier and even better
thing would be if they actually used Erlware to build the Erlang source
code; then we could all build it with Erlware and the main objection
would be solved. Also, they could put some resources on it to help with
the wrinkles.
Just dreaming ;)
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090215/dd035b5b/attachment.bin>
masklinn (Masklinn)
2009-02-16 23:33:59 UTC
Permalink
Post by peter (Peter Sabaini)
Post by erlang (Joe Armstrong)
This is my take on the matter.
To start with I don't think one distribution scheme or library will
ever work - the work
making it consistent is colossal.
Yet rubygems or PyPI seem to work out quite well.
Or Cabal for haskell, or CPAN for perl, or the various OS package
systems.

All of these typically have issues here and there (pypi/easy_install
being the worst of the bunch imo), but that's a case of "practically
beats purity" and "now is better than never". Lib packaging/
distribution is a fairly hard (and not-yet-completely-solved) problem,
but having something that kinda works clearly beats having nothing at
all. And one can step on the shoulders of giants to learn from their
mistakes.

rapsey (Rapsey)
2009-02-15 13:44:52 UTC
Permalink
How about a quality release with a small subset of the final functionality?


Sergej
Post by erlang (Joe Armstrong)
This is my take on the matter.
To start with I don't think one distribution scheme or library will
ever work - the work
making it consistent is colossal.
I rather like what's happened in the javascript world.
Here there is a core-language, and alternative sets of rather-good libraries.
To me a good library has
- a book (or books) -
- community who contribute to the library
- a unifying principle
- a set of applications that use the library
The javascript jquery and protoype libraries live up these criteria.
After I finished the erlang book I started writing a library and a number of
a) write a base library and applications
b) open source it and invite community participial
c) improve quality of library through participation
d) write a book describing the library
I'm in the middle of a) - I now have a dilemma, should I release now or later.
advantages: early feedback
disadvantages: quality problems - it's in a bit of a mess, so it gets
a bad reputation.
advantages: higher quality of release
disadvantage: loose user feedback
Do you want software "early and buggy, badly documented" or
"late and better documented, higher quality"
I would welcome some feedback here
/Joe Armstrong
On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <watson.timothy>
Post by watson.timothy (Tim Watson)
Post by erlang-questions_efine (Edwin Fine)
I am using sinan/faxien exclusively, and have installed and maintained four
Erlang production systems with them. There were some teething issues, some
This is interesting - I also started out with good feelings about
sinan/faxien, but they appear to redistribute the core OTP libraries
which is anathema where I work.
Martin & Eric can speak for themselves, but my point of view is that,
well,
they don't really redistribute them as such. They are forced to build
them
using their own tools and put them in their WebDAV repository because (a)
The OTP team doesn't support such a repository, and (b) they have to make
minor tweaks to the add their metadata, which is necessary for the
distribution mechanism. The metadata doesn't exist - or, in the case of
.app
files, sometimes doesn't quite fit in - in the OTP distribution. I am
pretty
(99%) sure there is no fiddling with the source code at all, it's just an
alternative way to build it, no more suspicious than building OTP from
the
tarball. If there was a way to build OTP with their (Erlware) tools in a
100% automated way, then anyone could do it, but they are not quite there
yet (as far as I know). So that is indeed a sticking point, I can see.
Post by watson.timothy (Tim Watson)
We're simply not allowed (by law) to
run code on "some version" of kernel/stdlib/etc that didn't come from
a verified (official) sources, even if it did in reality (if you see
what I mean). This is an issue of regulatory compliance, so we're
stuck and can't use the tools, which are (I agree) very nice bar some
minor usability issues. I suspect this puts a lot of people off - it's
not as maven downloads and installs the JDK for you is it, and for
good reason - I'd be surprised if that many people actually wanted
this.
Clearly there are mixed opinions about whether a repository for
publishing applications and a distributed build system that can
consume code from public/private repos, is a good approach. That's to
be expected, but this idea of redistributing "Erlang itself" is
another thing altogether. It seems like trying to force too many new
ideas at once, and I suspect this is a big part of the problem.
Again, I believe they don't WANT to redistribute Erlang. It's a huge pain
in
the butt to have to tweak new Erlang releases to build with their
toolset,
and it's not really the fault of their toolset, it's just minor
inconsistencies here and there that cause issues. If they could get it
right
that anyone could build Erlang itself using Sinan, and then put it in
their
own private Erlware repo with Faxien, these objections would largely go
away.
If you look at what Ruby has managed to achieve with Gems, and (I think)
Python with "eggs", it is quite reasonable to expect that we should be
able
to distribute our own Erlang apps in a pre-built form in a way that makes
it
really easy to update. I use this mechanism to update production servers
in
a number of different countries, and the previous way I did it was just
horrible. It's so much easier for me just to log into the remote server,
type in "faxien upgrade-release myapp", maybe tweak the sys.config, and
then
restart the application (I don't need hot code update yet). The sad thing
is
that Erlware is *so* close to being really great, and is held back mostly
because the authors are so busy actually earning a living that they don't
have enough time to devote to ironing out the wrinkles.
My great hope is that the Erlang/OTP team will see enough merit in this
approach to make this a standard distribution mechanism, but I don't hold
out much hope (not because the team is unreasonable or anything, but
because
of the overhead of supporting builds across many hardware platforms and
version within the platforms.) An easier and even better thing would be
if
they actually used Erlware to build the Erlang source code; then we could
all build it with Erlware and the main objection would be solved. Also,
they
could put some resources on it to help with the wrinkles.
Just dreaming ;)
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090215/c6b06d0d/attachment.html>
twoggle (Tim Fletcher)
2009-02-15 14:10:15 UTC
Permalink
Post by erlang (Joe Armstrong)
Do you want software "early and buggy, badly documented" or
"late and better documented, higher quality"
I would welcome some feedback here
Is this the "70 module library"[1] that you have referred to before?

You're likely to be writing code that people want to use. Releasing it
earlier would provide an opportunity for feedback on the APIs, and get
you some help in finding/fixing some of those bugs.

In addition, i think an insight into where you are heading would be of
value, particularly if you are trying to develop tools, best
practices, and standards for meta data as you suggest in the
aforementioned discussion.

For me, this all outweighs any disadvantages of opening up early. I
would rather have something imperfect but that i could help improve.
If nothing else, sharing some more of your ideas/goals would be a good
place to start.


[1]: http://www.erlang.org/pipermail/erlang-questions/2008-November/039918.html
jan (Jan Lehnardt)
2009-02-15 17:13:09 UTC
Permalink
Post by erlang (Joe Armstrong)
I'm in the middle of a) - I now have a dilemma, should I release now or later.
Release early & often.

Cheers
Jan
--
getyourcontacts (Yang Zhang)
2009-02-15 17:39:11 UTC
Permalink
Just see a small question become a long long discussion. It has taken me 30+
minutes to check all posts above.

As most people talked here, I saw the point is the erlang distributors or
communities don't have central repository or proper library management.
That lead to DIVERSITIES(*diversities*). Many people implement what they
need, what they want and what they think to be useful,helpful and correct.
But I am wondering who can say fee's "urlencode" is better than Jan's
"urlencode", and who can promise Tim's implementation of "urlencode" is
correct? (Sorry. No mean to offend, just take name for example.)

If .NET/PHP/Python(I am not using Ruby or perl) don't provide their
urlencode or many common functions and leave them to people to implement
themselves, do you think they will become so popular? Be easy! Be simple!

.NET/Python drived me leave C/C++ because they are simple and with easy use
builtin libraries. And erlang's distribute feature drive me to writ
distribute server/application from .NET. When I was talking about the
distribute feature of erlang, it is so powerful, wonderful with .NET guys,
they were suggesting me to read some .NET books to learn MS's API, they said
.NET has builtin support to spawn process on another machine although they
know .NET don't have a mnesia. Then they concluded .NET is the best language
on windows platform. At least comparing to erlang, .NET is easier and more
stable(with excepted memory crash).
Erlang vm's crash was one thing someone was laughing at(If you check my
another mail).

Anyway, *diversities *is the bad thing here, for common/fundermental
functions, I really appreciate we can have an *offical *release so onbody
can write his own copy(saving time and be stable).

Sorry to extend this long discussion again.
Regards.
Scott
Post by jan (Jan Lehnardt)
Post by erlang (Joe Armstrong)
I'm in the middle of a) - I now have a dilemma, should I release now or later.
Release early & often.
Cheers
Jan
--
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090216/b2336636/attachment.html>
Continue reading on narkive:
Loading...