A better explanation for this language is at http://claylabs.com/clay/. The language focuses on improving generic programming by reducing template verbosity via "whole program type propagation".
I perused the documentation briefly and was left with the question: What does this allow me to do now that was previously impossible and/or extremely difficult.
Not saying anything bad about the language itself, as I've not used it, but the documentation that is linked does not give me any idea as to why I might want to try it.
It's an expressive systems language with lambdas. So, anything you would be using C for + the power you get from lambdas and generic types. In a way you could think of it as Go with a more advanced type system, and without the garbage collection.
I'm looking forward to writing a game in Clay to measure its true performance in a realtime system.
It looks like glut and opengl are included with the standard libraries. Unfortunately I can't find any building information so I can't do anything with it.
It means that you have to make sure to deallocate any memory you allocate when you are done with it. Basically, the same as C and C++, as opposed to garbage-collected languages like Python or Java, which will automatically detect when you are done with a chunk of memory and deallocate it for you.
It's quite refreshing to see a new language that doesn't have garbage collection. Memory leaks have always been less of a problem for me than the kind of performance hit GC can cause (particularly in games).
Does the type system help out in any way with this? I know linear types can be used to enforce memory management, but IIRC (I haven't looked recently) Clay's type system was more oriented towards generics than this sort of strictness.
You're correct; Clay's type system doesn't help much with memory safety. It's flexible enough to express RAII-based ownership semantics like C++, so you can manage dynamic memory with reference counted, uniquely-owned, or other policy-enforcing pointer objects, but also like C++, the language doesn't prevent you from taking nonowning references to arbitrary data behind the type system's back and using those references after the owning object has freed the data.
This is a strong statement for a language to make, but it actually makes it much more interesting.
To me, this says "Clay should be used to implement the same kind of hard-core stuff that is still implemented in C++": games, interpreters, compilers, browsers, etc.
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.
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?
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.
