On Thu, Jul 25, 2013 at 10:47 AM, Jonathan S. Shapiro <[email protected]>wrote:
> GC doesn't need to be the only mechanism or even the majority mechanism, > but it needs to be part of the portfolio, and it's been shown repeatedly > that it can't be done in a library. If nothing else, accurate GC support > imposes constraints on the optimizer and code generator. > This may be true from a theoretical standpoint, but I think practical issues push in a different direction. If there is GC, then (most) libraries are built assuming GC and it becomes effectively impossible to use that system without GC.. (unless you rewrite the entire world, at which point the language itself is the least of your worries) This suggests a much clearer dichotomy between strictly "GC-or-not", which very much mirrors what has evolved in real systems. I see it as a bit of a quantization problem. It's certainly possible to have hybrid systems, it's just that there is so much less human effort expended building an entire ecosystem of libraries as either a non-GC or full-GC system that half-GC is not a stable state for a single language IMO. I think this is what is effectively pushing Rust into non-GC. (I think their aspirations to do GC in a library will disappear eventually, except maybe ARC)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
