3 ms·

I found interesting what Rust's Graydon Hoare had to say about it: "It's very similar to earlier versions of rust. In terms of actor local GC, language provide

by tcard 11y ago

I found interesting what Rust's Graydon Hoare had to say about it: "It's very similar to earlier versions of rust. In terms of actor local GC, language provided scheduling of actors, separated function and async invocation system, mixed structural and nominal types, and an overabundance of language supported reference qualifiers. I think they did a good job at it, certainly much better than I did, but I'd be nervous about the cognitive load of the reference qualifiers (capabilities). See this page for example, or the previous few in the tutorial. We had that sort of cognitive load on variables early on and people basically rejected the language because of it, as well as associated compositionality problems. The many years of design iteration had a lot do to with factoring that space into fewer, more essential and general qualifiers. Slow, tedious, world breaking refactoring work. I hope for pony's sake this doesn't happen to them too -- it looks really nice -- but that's my biggest worry for it." http://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_safe_language/cqxkmm8 http://www.reddit.com/r/rust/comments/34rszb/pony_type_and_m...

SnowyOwl 11y ago
Indeed, the type system when explained in detail is not that simple. Nevertheless, we believe that it can be used without detailed knowledge. In our experience, programmers can pick up the system fast (e.g. after a 2 hour discussion). Similarly, programmers can easily write programs which type-check, even if they do not have a deep understanding of the type system (e.g. they need not memorise the table you mentioned). Type-checking is enough - given the guarantees by the type system, (data-race freedom and atomicity). The use of defaults reduces the annotation burden - typically to only 10%-20% of locations which allow them.
decklebench 11y ago
Thanks for the positive tone! Regarding annotations, the "Fast & Cheap" paper contains the following: The language uses carefully chosen default capabilities to minimise the required annotations. In addition, the compiler guides the programmer as to which annotations should be used, infers annotations locally, and performs automatic recovery in some circumstances. As a result, when implementing LINPACK GUPS (in app. F) we require just 8 capability annotations and 3 uses of recover in 249 LOC. In approximately 10k LOC in the standard library, 89.3% of types required no annotation.
renox 11y ago
This is bike shedding but I wonder if better names for the capabilities could help? box --> view (as in view but don't touch) or ro(read-only) trn --> once

by tcard 11y ago

SnowyOwl 11y ago

Indeed, the type system when explained in detail is not that simple. Nevertheless, we believe that it can be used without detailed knowledge. In our experience, programmers can pick up the system fast (e.g. after a 2 hour discussion). Similarly, programmers can easily write programs which type-check, even if they do not have a deep understanding of the type system (e.g. they need not memorise the table you mentioned). Type-checking is enough - given the guarantees by the type system, (data-race freedom and atomicity). The use of defaults reduces the annotation burden - typically to only 10%-20% of locations which allow them.

decklebench 11y ago

Thanks for the positive tone! Regarding annotations, the "Fast & Cheap" paper contains the following: The language uses carefully chosen default capabilities to minimise the required annotations. In addition, the compiler guides the programmer as to which annotations should be used, infers annotations locally, and performs automatic recovery in some circumstances. As a result, when implementing LINPACK GUPS (in app. F) we require just 8 capability annotations and 3 uses of recover in 249 LOC. In approximately 10k LOC in the standard library, 89.3% of types required no annotation.

renox 11y ago

This is bike shedding but I wonder if better names for the capabilities could help? box --> view (as in view but don't touch) or ro(read-only) trn --> once