On Sat, Jul 27, 2013 at 9:10 AM, Ben Kloosterman <[email protected]> wrote:
> I don’t think this is the reason .. in rust most of the devs are C++ and C > ( though the guy who was doing the stdlib also did the javascript one) and > so far they havent used the GC in the libs at all.. > Umm. There's a long history of C and C++ programmers having severe allergies to GC. Setting aside the level of allergy, switching mindsets to make effective *use* of GC takes a while, and doesn't really begin until you stop fighting city hall. The fact that most of the Rust libraries do not allocate on the GC heap is not necessarily a good sign of effective storage management. > Now obviously standard libs tend to have short lived objects … They do > realize that libs with long lived objects and eventing libs will need ref > counting and gc but they do that now with C++ so , you can remove all those > ugly @pointers from the language , make all pointers local/region and use > an external lib. > That may or may not be true - I could give a number of key counter examples. But what *does* seem to be true is that trying to drive the language design based on the somewhat unusual behavior of standard library code seems like a mistake. > Personally I think the compiler can infer what is needed most of the time > ( local or long lived) and you can use a specific syntax when needed ( eg > define on an interface that is publically visible) . > Yes. And better still, a tool can tell you which is which and help you make the right annotations. There's an interesting philosophy question concerning whether prescriptive annotations can or should be removed from the language if inference and tools can make things clear. One might, for example, relegate some of this to attributes and an offline checker. I personally do not think they should be removed. In my opinion, the programmer *does* need a way to presecriptively express their intent. It's a contract issue. The one hesitation I have on that is that the automatic analysis of heap classification is done by algorithms that are necessarily heuristic. Two compilers, using different algorithms, might legitimately infer different answers. This is why the treatment of poitners requires prescriptive keywords. There is also a case to be made for a line in the sand between *semantics* and *performance*. A compiler that simply places all objects in the GC heap is correct w.r.t. semantics. I'm not real comfortable with that position, but it's worth considering when we get to the point that we understand the limits of the inference mechanism. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
