On Sat, Jul 27, 2013 at 9:10 AM, Ben Kloosterman <[email protected] <mailto:[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. Agree.. note NONE of the libs ..not just some.. Re effective use of GCs this is not just C/C++ devs but even many C# and Java devs I have seen.. "Out of sight , out of mind".. and this is a huge issue. As we have mentioned people can do a lot more to reduce GC strain and effective heap size but there are few courses or tutorials on the subject. 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. I don't think it is just based on the lib code but their experience as C++ developers and for a C++ dev the lib code behaviour is standard... To the some of the devs (I feel ) rust is C++ with type classes , type and memory safety and some improvements like matching.. 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. Yes I was thinking of an attribute on the interface first but for something so important don't think its right to deny the ability to be explicit Ben
<<attachment: winmail.dat>>
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
