Erlang futures

[Sean Hinde]

> 
> > Erlang has strings :) They are implemented as lists but I 
> have not had any
> > great problem with this and it makes for very easy 
> programming. They can be
> > stored in mnesia as binaries if you want to save the last 
> few bytes of
> > memory.
> 
> I was under the (perhaps incorrect) impression that the 
> overhead of those
> "last few bytes of memory" was something like 7 bytes per 
> character in the string.

Yes, you are correct. It is the last few bytes if you are storing a few
strings. If you are storing War and Peace then it's the last few Megabytes
:)

> It's the old "Bloatware == ease of use" trade-off that 
> produces animated talking
> paperclips.

Well perhaps not quite that bad. I guess most Ericsson apps to date haven't
needed to store anything like gigabytes of strings. More like a few web
pages for config.

But, since XML is becoming a bigger and bigger part of even core telecoms
that must surely be a good driver for Eri to come up with a more optimised
string type..

Here's hoping for something in R8.

What we do here in the meantime is store large strings in mnesia as binaries
and if we need to have string representation after a read then just convert.
Higher temporary memory usage but pobably not enough to preclude the vast
majority of apps.

Feedback from users of our INETS based apps including XML services are that
they simnply cannot believe that p[ages are not served locally. The realtime
scheduler makes for an incredible user experience in these sorts of
environments. Erlang may not be as outright fast as OCAML but user
experience is likely to be better for much less programming effort.

> Not that animated talking paperclips are _necessarily_ all bad.

Grrrr

- Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.