[erlang-questions] Re: Distributions of Erlang-coded SW on Windows (really)

Ulf Wiger ulf.wiger@REDACTED
Fri Aug 14 16:41:06 CEST 2009

Benjamin Tolputt wrote:
> Michael Turner wrote:
>> Look, this was a serious question about packaging, not quality or, for
>> that matter, open source ideology.  <snip...> Packaging matters.
>> as a "platform".)
>> Windows is not going to vanish tomorrow.  It's probably got another 15
>> years in it.  Packaging Erlang-coded applications so that they seem to
>> be regular full-fledged Windows apps might smack of treason to some, but
>> it might also help push Erlang into the mainstream of programming
>> practice.  And I don't see how that hurts anybody here.
> I whole-heartedly agree with the above. Erlang/BEAM is a powerful
> platform that could have a wide variety of uses. In fact, I believe the
> idea of a quick & easy packaging method is something that would benefit
> Windows & Mac OSX users (my current client application targets).
 > That said, others have achieved this without serious difficulty. For
 > example, check out Wings 3D - one of the most intuitive mesh modelling
 > applications I've had the pleasure to use. It use Erlang, as the
 > original authors were quite enamoured by the language, and runs on
 > Windows, Linux, & Mac without issues.
 > Perhaps what you are after is something more automated than their
 > method, but there are ways to deploy applications in a quick & easy
 > fashion for Windows platforms :)

AFAIK, Sinan (part of erlware) doesn't work on Windows yet.


I'm sure the erlware developers would love to get some
volunteers on this front.

Erlware does aim to address not just the quick install,
but continuous operation as well.

>> So if somebody has an actual *helpful* answer to these sorts of
>> questions, count me among the interested.  After all, I want real users
>> for what I write, and most of them will be on Windows, and I don't want
>> to ask too much of them, or they will go away.
> And this is where I start to disagree. Not so much with your desire to
> get more helpful answer, but with the idea that applications not running
> on Windows boxes are somehow less important than those running on other
> platforms (if that was not what you meant by "real users" than I
> apologise).

There is also the issue that many of those who are in
possession of knowledge that would be helpful may choose not to
answer due to /time constraints/ - not necessarily because
they are unwilling to share.

> Erlang/OTP is, by design, a platform best suited to running servers.
> Client applications generally don't need to be running thousands of
> processes (with the possible exception of games - my particular
> interest), so the primary benefits are lost. Not that they aren't useful
> or such like, just that the benefits Erlang can provide give best "bang
> for your buck" on server architectures :)

There are other aspects of Erlang that /are/ helpful even
if you don't require massive concurrency.

Even with modest concurrency, the erlang way of modeling
with processes and message passing is powerful in its own
right, as is the out-of-band error handling and "programming
for the correct case" mentality.

> As such, I've found Erlang developers are less worried about the ease of
> initial deployment (especially on Windows platforms) because it is not
> that common an occurrence for them. Updating an existing deployment on
> the other hand is a well explored topic.

This is largely true for the /paying/ customers of Erlang
(i.e. the internal Ericsson projects.) The OTP team will do
stuff for money. Unfortunately, there is no channel for getting
money to them from the outside... yet.

May I also point out that there are companies - not just
Erlang Training and Consulting - who are more than happy
to focus on improving Open Source components if you pay
them. The work may be done anyway, perhaps even by the
same companies, but asking someone to make something a
/priority/ usually costs money.

Ulf W
Ulf Wiger
CTO, Erlang Training & Consulting Ltd

More information about the erlang-questions mailing list