[jckarter]

Clay is a lot more flexible and metaprogrammable than Rust. Clay allows ad-hoc overloading with predication based on arbitrary compile-time computation, whereas Rust's polymorphism support is more strictly based on Hindley-Milner parametric polymorphism and type classes. On the other hand, Rust, by baking features like shared/unique pointers and logging into the language, is able to provide much stronger safety guarantees with a much simpler type system than Clay would need to provide the equivalent guarantees. Rust also requires a runtime, which supports some cool features like lightweight tasks, cycle collection, and builtin logging, whereas Clay sticks to a "no runtime other than libc" mandate. Overall, Rust will probably be a much better choice for large-scale application development than Clay. The cool thing about Clay is that it's like a scripting language for LLVM. It's great for flexibly generating small amounts of native code without runtime dependencies.

[zokier]

This certainly piqued my interest. Do you reckon that eventually some of the interesting features (such as tasks, channels and smart pointers) of Rust could be implemented in Clay as libraries, with type safety and everything?

[jckarter]

Clay has shared and unique pointer implementations in its library. Naive channels could be mostly implemented in the library as well, but I think they might need language support to pull some of the tricks Rust and Go do to make them fast, and Clay's type system would need to better guard against unintended sharing to make them safe. The Rust and Go developers are contributing the groundwork for lightweight tasks into LLVM, so with runtime library support Clay could potentially inherit that support. I think a region type system would fill in the safety holes; the Deca language (http://code.google.com/p/decac/) is very similar to Clay (no runtime requirements, variant-based dynamic dispatch) and successfully uses region typing to provide safe memory access.