[erlang-questions] Re: Shared/Hybrid Heap

Tony Arcieri <>
Thu Nov 4 00:50:47 CET 2010


I agree with this sentiment as well. A pure immutable system gives more
optimization options to VM implementers, but as is without the shared/hybrid
heaps Erlang doesn't do a good job of leveraging the potential of a purely
immutable state system.

On Wed, Nov 3, 2010 at 5:35 PM, Ryan Zezeski <> wrote:

> On Mon, Oct 18, 2010 at 7:28 AM, Morten Krogh <> wrote:
> >
> >
> > On practical terms, I feel that Erlang some times gives up performance
> for
> > unnecessary reasons. I am especially thinking about mutability.
> > There is no reason to give up mutation within a process which is already
> a
> > serializer.
> >
> > code like this
> >
> > loop(Dict)
> >    receive
> >    {put, K, V} ->
> >        Dict2 = dict:store(K, V, Dict),
> >        loop(Dict2)
> >    end.
> >
> >
> > is just a performance wise inefficient way of doing
> >
> > loop(Mut) ->
> >    receive
> >    {put, K, V} ->
> >        put(K,V, Mut),
> >        loop(Mut)
> >    end.
> >
> > where Mut is a mutable data structure.
> > In the dict exampe, there is a unncecessary work and garbage collection
> for
> > the functional data structure Dict.
> > And you gain nothing, since it is sequential code.
> >
> >
> I think this is a good point.  If you are simply creating a data structure
> in _one_ process it should be mutable.  Then when you publish it it becomes
> immutable.  I have Clojure's transients in mind.
>
> http://clojure.org/transients
>
> *If a tree falls in the woods, does it make a sound?**If a pure function
> mutates some local data in order to produce an immutable return value, is
> that ok?*
> *
> *
> *
> *
>



-- 
Tony Arcieri
Medioh! A Kudelski Brand


More information about the erlang-questions mailing list