On Sat, Jul 27, 2013 at 9:59 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 1. *Distinction between heap and stack is hard to grasp*. Umm. That's a > hell of an indictment of computer science programs, but not a criteria for > language design. > I agree and I honestly don't understand why he included this point. In fact, I think stack-variables are quite easy for programmers to understand, witnessed by the fact that they are frequently used without trouble. IMO, the stack *related* difficulty lies with default behaviors for reference-vs-copy-vs-deepcopy and how each language defines implicit rules about how these semantics apply in contexts such as stack-vs-heap, assignment, type-declarations, paramater-passing, etc. Perhaps this is what he was thinking of? > 2. *Sigils make the code unfamiliar before the concepts are learned*. > ...I am inclined to think, with no supporting evidence whatsoever, that > simply shifting to English keywords would make a world of difference. > I don't think the punctuation is really an issue. I think the trouble is that most people coming to Rust have never used anything like owned pointers, borrowed pointers, or lifetimes. Understanding how do decompose problems into these concepts requires time. But more importantly, shifting most of this burden to the compiler would > make an even bigger difference, and in most cases the compiler is where it > belongs. > Certainly non-escaping argument status can be inferred in many cases. However, how does a compiler automatically make a choice about whether a library allocates something for return on the GC-heap or stack+borrowed-lifetime-pointer? > 3. *There are two heaps, not just one, so beginners are confused as to > which one to allocate into.* Well, yes. That really *is* confusing. And > it's compounded by the fact that (a) while you want a keyword for > prescription, discovery of unique pointers can be entirely automatic, and > (b) Rust advocates the wrong default (owned pointer), and (c) for most > purposes it's completely unnecessary. Owned pointer is the wrong default > because we teach general-purpose programming, and the semantics of an owned > pointer isn't general purpose. > This sounds like a slippery slope which would turn Rust into yet another GC language. I don't really understand the value in that. C/C++ have utility beyond GC languages because they don't admit GC, but they are filled with safety holes. Rust is trying to plug many of those safety holes while still being free of the trappings of GC. It may not be the path of bitc, but it sounds like a worthy goal to me, at least until bitc gives us a tradeoff free GC model. > 4. *Programmers don’t know which to use, since some operations are > available with ~ and some operations are available with @*. Well hmm. > It's not clear to me what operations aren't supported on both pointers, > A linked list designed to avoid GC-tracing takes an owned pointer version of it's payload. If it accepts a GC pointer to it's payload, then the entire linked-list must be traced to trace those embedded GC pointers -- negating the benefit of using owned pointers to begin with. This analogy extends to any owned-pointer-capable data-structure implementation. > Within point 4, there is a key mis-statement: > > The key insight that was missing is that *the owning pointer ~ is just > the Rust equivalent of malloc and free*. > > > This statement is flatly wrong, because the two aren't equivalent at all. > Rust's owning pointer is a degenerate region allocation (degenerate because > they don't - or at least didn't - have a proper region system). That's not > the semantics of malloc/free at all. > Why did-you/do-you think this? By my view owning pointers are a form of linear-types, and borrowed-pointers and lifetimes are an attempt to extend the scope within which Rust can share direct references to linear-type-ish owned-pointers. If I understand region systems at all, they don't in themselves establish liveness for objects in the region. The region must be GCed if one wishes to reclaim elements no longer referenced in a dynamic region. Rust owned pointers do not suffer this problem. As soon as they are discarded, they are reclaimed, and it is assured there are no other references to the discarded subtree of owned-pointer-data. So with those four points examined, the thing to notice is that *not a > single statement is made here explaining why GC is undesirable*. *Why* should > owned pointers be "the go-to solution" in Rust? Especially when we know > that such pointers lead to false liveness! I'm having trouble finding the > reference at the moment, but there was a paper or a tech report by Andrew > Appel examining the impact of false liveness (pointers you are done with > but are still in scope) in precise collectors. From memory, I think the * > typical* false retention overhead was around 17%-20%, and in some cases > where event loop programs retain a top-level pointer it was effectively > 100%. Owned pointers should be expected to have similar retention problems, > though at least without the consequent collector overheads. > ...Not if you treat owned pointers as Rust's malloc-and-free, and explicitly free them when you know you're done with them. For me, a systems programming language is expected to help us construct the programs we want, and when it can't do that, it's expected to at least get out of the way and do what we want. I think this is the motivation they are driven by. (see other thread on systems programming language definitions)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
