[erlang-questions] Is erlang a web language?
Sun Feb 15 14:44:52 CET 2009
How about a quality release with a small subset of the final functionality?
On Sun, Feb 15, 2009 at 12:56 PM, Joe Armstrong <> wrote:
> 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.
> Here there is a core-language, and alternative sets of rather-good
> 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
> After I finished the erlang book I started writing a library and a number
> 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
> 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 <>:
> > On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <>
> > 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,
> > they don't really redistribute them as such. They are forced to build
> > 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
> > files, sometimes doesn't quite fit in - in the OTP distribution. I am
> > (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
> > 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
> > the butt to have to tweak new Erlang releases to build with their
> > 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
> > that anyone could build Erlang itself using Sinan, and then put it in
> > 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
> > to distribute our own Erlang apps in a pre-built form in a way that makes
> > really easy to update. I use this mechanism to update production servers
> > 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
> > restart the application (I don't need hot code update yet). The sad thing
> > 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
> > of the overhead of supporting builds across many hardware platforms and
> > version within the platforms.) An easier and even better thing would be
> > 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,
> > could put some resources on it to help with the wrinkles.
> > Just dreaming ;)
> > _______________________________________________
> > erlang-questions mailing list
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions