<br><br><div class="gmail_quote">On Jan 29, 2008 10:21 PM, Mikael Pettersson <<a href="mailto:mikpe@it.uu.se">mikpe@it.uu.se</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jonathan Amsterdam writes:<br>...<br>[GC 101 omitted]<br>...<br><div class="Ih2E3d"> > I haven't looked at the code for the Erlang GC, so I don't know how<br> > amenable it is to these changes. I just wanted to dispel some of the<br>
 > fear I imagine I hear when people intone "write barrier." Or maybe I<br> > am missing something, in which case I would appreciate being educated.<br><br></div>The core Erlang developers are well aware of the techniques<br>
needed to support destructive updates in GC:d heaps.<br>There are however several other issues to consider:<br>1. Adding write-barriers/remembered-sets or their equivalent<br>   to the GC would complicate an already complicated and<br>
   delicate part of the runtime system, which is not always<br>   a win if you're aiming for five-nines robustness.<br>   The runtime cost of the write-barrier is a non-issue,<br>   since writes can be expected to be rare. Erlang is not<br>
   Java, thankfully.<br>2. As soon as destructive updates are supported, people<br>   will use them. From what I've heard from Ericsson folks,<br>   the lack of destructive updates is actually a positive<br>   thing for them, presumably due to program reliability and<br>
   programmer productivity.<br>3. The combination of message passing and mutable data breaks<br>   the semantics of Erlang, or that of mutable data, and limits<br>   the choices the Erlang implementors can make. Suppose P1<br>
   sends a term T to P2. P2 inspects it. Later, P1 updates<br>   some part of T. Should P2 observe that change?<br>   - if yes, the semantics of Erlang is now fundamentally altered,<br>   - if no, the semantics of mutable data is severely restricted.<br>
   Furthermore, each choice creates new hard constraints on how<br>   the runtime system may implement process heaps and message<br>   passing.<br><br>So the real question is not whether adding updateable terms to<br>Erlang is possible (several people could do it, myself included),<br>
but whether it's desirable. And on the whole, I think Erlang is<br>better off without them.<br></blockquote></div><br>+1<br>robustness, reliability, programmer productivity - It is why I like Erlang without <span id="1epx" class="VrHWId">destructive updates. Performance is on second place.<br>
<br></span>-- <br>--Hynek (Pichi) Vychodil