On Sat, Jul 27, 2013 at 8:29 AM, Jonathan S. Shapiro <[email protected]>wrote:
> On Fri, Jul 26, 2013 at 10:01 PM, David Jeske <[email protected]> wrote: > >> On Fri, Jul 26, 2013 at 7:56 PM, Jonathan S. Shapiro <[email protected]>wrote: >> >>> ...What I *am* hoping to do is to use compiler magic to reduce the >>> utilization of the GC heap so that GC pressure and/or total RAM >>> requirements are suitably reduced. >>> >> >> ...Understood. Let me rephrase my point. Using this magic is a necessary >> but not sufficient condition to achieve a practical typesafe GC-free >> capability. >> > > Agreed. So let me say it one more time: That. Is. Not. A. BitC. Goal. > I misunderstood. Your comment about the allocation-free main deduction confused me. I thought it would never allow non-safe memory use, not that it would always use GC. I understand now. What kinds of libraries were they interested in where GC was a concern? It > also occurs to me to ask: why is the Rust team trying to eliminate GC? > Where did it get in the way, and is it an inherent consequence of GC or is > it a consequence of a poorly implemented GC? These are good questions. This blog post offers some commentary on the issue. It sounds to me like it's not so much that they are trying to eliminate GC, but that they want to be able to write Rust code without GC's costs, which led them to owned-and-borrowed pointers, and then they decided they'd like to focus on that for the core and push GC out for now. http://tim.dreamwidth.org/1784423.html Unfortunately, I think that in deciding to remove GC from the language they > are removing the part of the pointer system that is general-purpose, > coherent, and explicable, and committing themselves to the part that > currently consists of complex and non-connected corner cases. On the contrary.. If they made GC pointers the easy default, most libraries written would make heavy use of the GC, and programs written in Rust would always be saddled with GC laiden performance consequences. If someone hands them a no-cost GC implementation, I'm sure they would include it directly (as would we all!)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
