[erlang-questions] Is erlang a web language?

[Tim Watson]

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).