Strings (was: Re: are Mnesia tables immutable?)

[Christian S]

On 6/28/06, ke han <ke.han@REDACTED> wrote:
> In the example I gave, my countryManager process is a singleton (pardon the
> oo pattern reference, but thats what it is) that serves the entire VM to
> answer a list of countries.  This is a lengthy list of short utf-8 encoded
> binaries.  So wouldn't the list get copied?  And won't each short binary in
> the list get copied as well?  There must be a better way.

When benchmarking, how fast could you serve requests to your
countryManager? (Btw, registered process would be more erlangy than
'singleton')

What job does it do?

> In order to get around this problem, I would have to destroy MVC separations
> and have my model object (countryManager) return an already serialized
> binary of binaries (or if I'm going to do that I may as well have the
> countryManager go ahead and serialize it to json form as well).
> This violates lots of sounds application design.  Basic principles of
> encapsulation and separation of presentation and app logic are well grounded
> in OO design.  These principals apply to non-OO languages as well.  I
> understand that not having object references and copying terms between calls
> to erlang processes is a key element of erlang.  But for non-mutable
> strings??? Not having a solution for this makes mainstream web apps very
> inefficient.

Since we have first class functions in erlang you can pass your
countryManager process a function that process the data it has, and
send you back only the result of that call. No violation of sound
application design. This is a trick languages without first class
functions have a hard time to take advantage of, luckily Erlang is not
that crappy.

You keep mentioning non-mutable strings as we had mutable strings. We
have ways to modify bindings (process dictionary or ets) but not to
manipulate the string value itself (hipe extensions ignored). The
later is a good thing nobody want to give up.

Where are your benchmark that show how mainstream web apps in erlang
are very inefficient? Maybe you are just doing the wrong thing?