It may not be a goal but if you were to fork rust which is where this thread started would you deliberately take the capability away ? It could be quite useful - especially till an all singing and dancing GC comes on line . I think this is why David is probing.. I'm not forking Rust. They've made too many design choices and implementation choices that I think won't work. And yes, if I did, I would actively remove Rust's current pointer mechanisms. At present, they are poorly designed and framed, which is causing so much confusion that even the Rust team is making bad decisions grounded in that confusion. Agree on some of their design decisions, but it is an almost v1 system that is a huge + .. It is easier to change some of these mechanism than build a whole new eco system , systems spend years in development and longer in research . I think Rust has a damn good shot at the systems program area ( eg drivers , embedded systems , kernels , runtimes etc) , however it is not great for larger apps like 3D games , distributed systems etc which is a huge hole for a rust+ type system. While I like .NET , I really don't think you will get much traction from existing C and C++ devs with a GC on .NET and mono is worse , it would need an overhaul of mono or something catchy . It's just a poisoned chalice after so many years , it's like trying to get devs to use inline braces .. For openwinrt I was thinking you can use winrt api which has the beauty of linking C++ native and .NET apps together - that's the kind of hook you need. The GC makes it worse , I'm sure such a GC can be built ( along with teaching some GC techniques) but its difficult and expensive to build test and tune yet alone coordinating it with a compiler. Java would benefit and such a GC would be a big market commercially - yet they can't get such a GC of the ground . With a rust type system you can rely less on the gc initially and as the language gets used on bigger project the GC can gradually improve. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
