[erlang-questions] Is erlang a web language?

[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
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



2009/2/15 Edwin Fine <erlang-questions_efine@REDACTED>:
>
>
> On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <watson.timothy@REDACTED>
> wrote:
>>
>> >
>> > 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.
>
>> 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@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>