<story><title>The Rust Programming Language</title><url>http://dl.dropbox.com/u/4186469/rust-all-hands-w2011/assets/fallback/index.html</url><text></text></story><parent_chain><item><author>mkup</author><text>I&apos;m writing this comment in hope that Rust language designers read this thread.&lt;p&gt;It&apos;s very important to language designers at this time to avoid stop-the-world GC approach in Rust at any cost.&lt;p&gt;Google Go is beautiful programming language, but its key limitation is stop-the-world approach to GC which makes it very difficult to implement highload web servers, DB engines and other software with strict max-time-to-response requirements. Recent research [1][2] suggests that &quot;normal&quot; Go program spends more time collecting garbage than performing actual calculations.&lt;p&gt;[1] &lt;a href=&quot;https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf&quot; rel=&quot;nofollow&quot;&gt;https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...&lt;/a&gt;
[2] &lt;a href=&quot;http://www.theregister.co.uk/2011/07/01/go_v_cpluplus_redux/&quot; rel=&quot;nofollow&quot;&gt;http://www.theregister.co.uk/2011/07/01/go_v_cpluplus_redux/&lt;/a&gt;&lt;p&gt;Go programming language has gone too far to separate owning and non-owning pointers at syntactic level, to disallow changeable global variables, to enforce rules like &quot;each mutable object is accessible from &lt;i&gt;only one&lt;/i&gt; thread&quot;, and introduce other means to avoid GC.&lt;p&gt;But Rust is new and young, already has 2 types of pointers, and it could avoid GC by RAII and reference counting. Objects linked in cycles with owning pointers would cause memory leaks, and I think this behaviour may be left as is, kinda &quot;it&apos;s not a bug, it&apos;s a feature&quot;. Weak pointers could point to intermediary descriptor which holds owning-refcount and nonowning-refcount. Weak ptr behaves like a NULL if owning-refcount is zero and target object is already destroyed. This is to guarantee safe memory model.&lt;p&gt;In short please take all means to avoid main Go defect &quot;Garbage collection takes more CPU time than actual computations&quot;. Please avoid stop-the-world GC approach which makes the language almost useless for real applications.</text></item></parent_chain><comment><author>supersillyus</author><text>I&apos;m not sure that your premise is solid. Your citations point to a single program that was somewhat naively written, not well optimized, and designed as a computational benchmark spending much of it&apos;s time in GC. That&apos;s doesn&apos;t necessarily imply that &quot;GC takes more CPU time than actual computations in normal Go programs&quot;. That&apos;s not to say that Go&apos;s GC isn&apos;t slow, but as citation #2 shows, one can limit heap allocation if performance requires it.&lt;p&gt;So, the fact that you&apos;re saying &quot;Don&apos;t do what Go does, it makes Go almost useless for real world applications&quot; seems odd to be because:&lt;p&gt;1. Not all applications care deeply about stop-the-world gc pauses.&lt;p&gt;2. Not all of those that do will have a problem with them, as GC can be avoided by value semantics and escape analysis.&lt;p&gt;3. Go will not necessarily always have a Stop-The-World GC, though it does now. I don&apos;t think it&apos;s required by the spec.&lt;p&gt;4. People are using Go in real world applications, implying that it isn&apos;t almost useless. Even servers.&lt;p&gt;5. The Rust folks clearly have thought hard about efficient and scalable memory management, and the slideshow indicates that, so I&apos;m not sure why you&apos;re worried for them.</text></comment>
<story><title>The Rust Programming Language</title><url>http://dl.dropbox.com/u/4186469/rust-all-hands-w2011/assets/fallback/index.html</url><text></text></story><parent_chain><item><author>mkup</author><text>I&apos;m writing this comment in hope that Rust language designers read this thread.&lt;p&gt;It&apos;s very important to language designers at this time to avoid stop-the-world GC approach in Rust at any cost.&lt;p&gt;Google Go is beautiful programming language, but its key limitation is stop-the-world approach to GC which makes it very difficult to implement highload web servers, DB engines and other software with strict max-time-to-response requirements. Recent research [1][2] suggests that &quot;normal&quot; Go program spends more time collecting garbage than performing actual calculations.&lt;p&gt;[1] &lt;a href=&quot;https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf&quot; rel=&quot;nofollow&quot;&gt;https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...&lt;/a&gt;
[2] &lt;a href=&quot;http://www.theregister.co.uk/2011/07/01/go_v_cpluplus_redux/&quot; rel=&quot;nofollow&quot;&gt;http://www.theregister.co.uk/2011/07/01/go_v_cpluplus_redux/&lt;/a&gt;&lt;p&gt;Go programming language has gone too far to separate owning and non-owning pointers at syntactic level, to disallow changeable global variables, to enforce rules like &quot;each mutable object is accessible from &lt;i&gt;only one&lt;/i&gt; thread&quot;, and introduce other means to avoid GC.&lt;p&gt;But Rust is new and young, already has 2 types of pointers, and it could avoid GC by RAII and reference counting. Objects linked in cycles with owning pointers would cause memory leaks, and I think this behaviour may be left as is, kinda &quot;it&apos;s not a bug, it&apos;s a feature&quot;. Weak pointers could point to intermediary descriptor which holds owning-refcount and nonowning-refcount. Weak ptr behaves like a NULL if owning-refcount is zero and target object is already destroyed. This is to guarantee safe memory model.&lt;p&gt;In short please take all means to avoid main Go defect &quot;Garbage collection takes more CPU time than actual computations&quot;. Please avoid stop-the-world GC approach which makes the language almost useless for real applications.</text></item></parent_chain><comment><author>pcwalton</author><text>Garbage collection in Rust is thread-local. We never need concurrent GC; this invariant is enforced by the type system.&lt;p&gt;Leaking cycles is not really an option, sorry. At the very least we&apos;re going to have a cycle collector. It&apos;s too easy to make cycles, especially when you have closures (all you need is to close over an object that contains a pointer to the closure itself; this is very common for e.g. event handlers).&lt;p&gt;Besides, a lot of the problems you state can be addressed with generational or incremental garbage collection.</text></comment>