[erlang-questions] Is erlang a web language?

[Edwin Fine]

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 ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090214/38e04765/attachment.htm>