

Clay 0.1.0 - Clay Programming Language - kristianp
http://groups.google.com/group/clay-language/browse_thread/thread/f7df29a245b2d1da?pli=1

======
mwexler
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".

------
mberning
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.

~~~
jb55
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.

~~~
Jimmie
Has anybody wrapped a rendering library, do you know?

~~~
jb55
There was an opengl library at one point, I'm not sure of the state of it now
though. I think it still works.

~~~
Jimmie
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.

~~~
jckarter
What build information is missing? The README.txt describes how to build the
compiler; it's a fairly typical cmake setup.

~~~
Jimmie
Yep, I'm an idiot. I grabbed the binaries from the official site instead of
from the repo.

I was tired.

------
niyazpk
Can somebody elaborate on what "No garbage collection" means? What are the
implications?

~~~
jdpage
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.

~~~
lemming
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.

~~~
jckarter
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.

------
zokier
Seems somewhat similar to Rust. How do they compare?

~~~
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.

