Clay – A language designed for generic programming | Hacker News Reader

Clay – A language designed for generic programming

claylabs.com

61 pointsX460 comments

In case anyone else is interested in C-replacement type languages, I've been collecting a list:

  ATS: http://www.ats-lang.org/
  BitC (seems to be dead): http://www.bitc-lang.org/index.html
  Tart: https://code.google.com/p/tart/
  Deca: https://code.google.com/p/decac/
  Cyclone: http://cyclone.thelanguage.org/wiki/Why%20Cyclone/
  Nimrod: http://nimrod-code.org/
  Habit (Haskell adapted for systems programming): http://hasp.cs.pdx.edu/

Plus of course the obvious ones, Go, Rust, D. I don't keep track of these projects' usability, I just write them down as I come across them.

We indeed have a similar list. Habit had slipped from my memory. I really wish Cyclone gets resurrected. There was quite a bit of discussion on HN when its closure(no pun intended) was announced. You may like digging into Felix.

Apart from this family the other I have been window-shopping on is the high performance/productivity family, consisting of the likes X10, Chapel and Fortress. Thanks to Oracle, Fortress is now abandonware.

Off late I have been quite disappointed by this trend in HN to be very hostile to things that I would consider to be the very distinguishing traits of a Hacker. Now it seems some people here compete to jump over the other to complain against things that encourage/facilitate or are meant for tweaking, learning, exploring and breaking: all things that I consider the very essence of hacking. Case in point, recent discussion on Gentoo.

The behavior reminds me of a bunch of desperate and wannabe Pink Floyd fans we had in college, who would jump to rally the crowd to disco to the opening strains of Another Brick in the Wall, much to our bewilderment but apparently to look cool.

There is always Java, if you are happy with it, stay happy with it.

I've actually never programmed in Java (just a little Clojure). I'm hoping to take a class in it this fall.

Felix is on my big list of interesting languages, but I didn't really think of it in the same category as these. I'm sort of aiming for something better than C when I get around to writing an OS kernel, you know, "someday".

I wrote a little OS dev 'starter' for Nimrod which might interest you: https://github.com/dom96/nimkernel

Oh! the Java comment was not for you.

I think for your use case decac, clay, bitC and Cyclone would indeed be ideal. There is this Haskell like language with effects based typesystem that might be worth looking at, the name continues to escape me.

One can go very low level with Felix, after all you can write inline C, C++ and define C and C++ functions, but those are not type checked. ABI could also be an issue given that it compiles to C++.

All the best for fun with kernel writing :)

> There is this Haskell like language with effects based typesystem that might be worth looking at, the name continues to escape me.

Disciple ? (DDC) http://disciple.ouroborus.net/

Don't say someday, look at Remo and do it like he did, just use one of these languages in your everyday projects.

http://www.codeblog.ch/2011/06/statically-linked-linux-execu...

By "someday" I mean "after I finish a bunch of other more pressing projects". ;)

Having such a list myself, I would add:

Myrrdin: http://eigenstate.org/myrddin.html

Pascal: http://www.freepascal.org/

Cyclone is pretty dead.

Good catch on myrddin. I had seen it before but neglected to write it down. I didn't really know pascal was in that space at all.

As the author of Myrddin, I'm kind of surprised that it's even been mentioned -- I'm not aware of it being used anywhere significant yet. (And the insignificant uses are just half-baked toy programs that I've written for myself).

It's pretty incomplete, and definitely not ready for prime time yet.

My list is not about "useable C replacements" ;)

I like to read about this stuff and compare design decisions between languages.

    http://code.google.com/p/june-language/ (java+python)
    http://code.google.com/p/j-rest/ (meta: api creator)
    https://code.google.com/p/szl/ (google data project)
    http://luvit.io/ (nodejs for lua)
    http://sourceforge.net/projects/sisal/

    http://zenlang.sourceforge.net/index.html (in dev)
    http://ufo.wikispaces.com/ (in dev)

Ok, the last one is a joke, but worth sharing, haha really funnny how people spent their time

    http://code.google.com/p/penor-programming-language/ (a joke?)

Thank you, that's cool! I have been looking for Deca for hours in my Bookmarks and the Web, didn't remember the name. (I have collected some languages to study too)

BitC isn't dead see here: http://www.coyotos.org/pipermail/bitc-dev/

Hmm, the last I remember hearing about it was a notice about how the creators were sort of giving up on it, and the website I had stored apparently hasn't been updated since 2010.

Yes, they plan to go a different direction, but it doesn't mean they give up with BitC (as of now), it's probably going to be refactored. The author discusses it in the 2013 post.

I'm not sure why people feel the need to be an asshole here. People develop new languages, they are not all meant to be production ready from day one. If the language is not interesting to you, move along.

yes I agree, one should respect the manhours put into it and evaluate it objectively before pouring in things that give others no better overview over it.

And in every language thread someone starts mentioning how good go is,.

Since the website is pretty bad at giving you a high-level overview, here are two projects using it:

- https://github.com/jckarter/Vinyl

- https://github.com/Blei/claytracks

I don't see anything here that would make me consider this over Go, though. Languages are rarely chosen based on their designs alone. Go is about as bleeding edge as I can get away with in my job.

A big problem is lack of good, built in UTF-8 support. But the no garbage collection thing is interesting as I didn't spot any explicit allocs or frees anywhere when I skimmed.

Go and Clay seem to have very different intentions.

Go is about concurrency. Clay is about generics.

Go is garbage collected; Clay is not. This allows Clay to be more suitable in environments where GC non-determinism/performance is unacceptable.

It's funny that Go keeps getting mentioned when people talk about new C-like languages because as you point out, it's not actually very C-like. In fact, the only thing that I'd say was truly C-like is the ability to create standalone executables. One of the dead giveaways is that most interest in Go seems to be coming from the Python community.

A better comparison would be Rust and Clay. Rust seems to emphasize correctness in the type system, Clay on making existing C++ style generics less cumbersome to use (a frankly laudable intention). On the other hand, I think it would be easier to give Rust the good things in Clay than the other way around.

Sure, I agree completely. But they're both systems languages. I write systems software, and Go already has barely any traction in the broader software community (outside of Hacker News...), so I have to choose what's easy to learn and has a reasonable level of support.

Languages always succeed based on support (documentation, community, tooling)--not features.

I brought Go up here because it stands the best chance of inheriting the role that C and C++ occupied for systems software, and which Python is also taking over. That's why it was created, so developers could have a statically-typed systems language that wasn't C or C++ or Python or Java, since all of those were unsuitable in various tasks for one reason or another.

because you probably don't know what to look at after all. Look at the predicated type declarations for example. It's a language with concepts built in.

I'm sure you didn't mean to be unnecessarily condescending with your reply.

I did not in fact read all 63 pages (!) of the language reference, but as for the predicated type declarations (found here[1], for the curious), I agree, they are very cool.

Let me clarify: I'm not saying the language does not have good parts to it. I'm not even saying that there's no room for a new systems language. I'm just saying for my use case, I can't justify using it and I'll stick with Go for now.

[1] https://github.com/jckarter/clay/blob/v0.1.0/doc/language-re...

I don't understand why modern languages still use the "mutli-value context" in place of tuples. When I first saw it in Matlab, I thought it was a mistake, and seeing it in Go and Julia reinforced this belief. IMO, tuples are superior in almost every way, as they are first-class, i.e. they act like any other values. They also avoid such sad patterns:

  record MyInt (value:Int);

  // delegate any function called with a MyInt to be called on its Int value
  [F] overload F(x:MyInt) = ..F(x.value);

where `..` must be used to extract multiple values in a single-value context. This could easily avoided using tuples.

The only advantage of Matlab-style multiple values is that they allow a kind of return-value type overloading, i.e. some Matlab functions perform less work if you don't only consume 1 return value. But I believe that this could be easily solved with a first-class code pattern.

What exactly do you mean by "multi-value context" and indeed "tuple" in this case? A tuple is traditionally an ordered list where the positions may or may not be assigned a name. When we assign names to the positions, we tend to call them "records". In other words the tuple [30, "Bob"] and the record {age: 30, name: "Bob"} are equivalent.

One language that prominently relies on tuples with unnamed fields, in the absence of a built-in record syntax, is Erlang. The downside to not having names is that to find a value you must know its position, which hides information in the implementation (refactoring the code in a way that changes the position, for example, might not result in a compile-time error), which is one reason that Haskell provides syntactic sugar for expressing tuple types using a record syntax.

One thing that Go does right is to sometimes allow you to address a record as a tuple:

    var x SomeRecord = {1, "Bob"}

However, when reading, I believe (I haven't actually checked) you can't access a record variable as a tuple.

By "tuple", I mean a first-class object that has multiple elements; an immutable list of sorts (and by "first-class" I mean an object that can be stored into a variable). E.g. in python:

  key, value = {'a': 1}.iteritems().next()

I could also do:

  item = {'a': 1}.iteritems.next()
  key, value = item

which shows that tuples are first-class.

By "multi-value context" I mean treating expressions differently depending on their context; some contexts are then "multi-value". E.g. in go:

  v, ok = a[x]

Here, if `x` is present in `a`, `v` is assigned the value at `x`, and `ok` is `true`; otherwise, `ok` is `false`, and `v` is assigned the zero value of its type.

Note that I cannot do this:

  pair = a[x]
  v, ok = pair

as `pair = a[x]` has a different meaning in this context: it only returns the value at `x` (or the zero value), and gives no indication of whether `x` is present or not. So, the meaning of the expression `a[x]` changes depending on the context, which can be either "single-value" or "multi-value".

Note that this does work just fine in Julia however since tuples are first class objects ;)

Maybe modern languages don't have tuples because modern programming language designers don't have any|much|enough experience with tuples? If I wanted to play with tuples, what language(s) would I have to use?

Python, or any of the functional programming languages: OCaml, Haskell, probably Scala. Tuples are really just syntactic shortcut for immutable lists, so Clojure would be appropriate as well, even though it makes no distinction between a tuple and a list (e.g. "rest" parameters to a variadic function are a list).

what about python?

This is weird:

    "In Clay, all arguments are passed by reference."

Looks like a nest of bugs waiting to grow as new users try out the language.

This is how the majority of dynamic languages do argument passing (Java/C# etc)

No, it isn't. I mean, it's possible to call what the majority of dynamic languages do "passing by reference", but it isn't the same thing as Clay does.

In C#, if I do

  int foo(int x) { x += 1; return x; }
  ...
  int x = 3;
  foo(x);

then afterwards the value of x is still 3. In Clay, if I do

  foo(x : Int) { x += 1; return x; }
  var x = 3;
  foo(x);

then the value of x is now 4. I agree with the grandparent: this seems like a really terrible idea. (In fact, I was going to post a comment saying so until I saw that someone else had got there before me.)

[EDITED to add: By the way, usually "dynamic languages" means "languages with dynamic typing", and Java and C# would be excellent examples of widely used languages that are not dynamic in that sense. The question of whether values are passed "by object reference" (my preferred way of describing what they do) is pretty much entirely separate from whether the language is dynamic. For instance: C++ (not dynamic, not p.b.o.r.), Java (not dynamic, p.b.o.r.), MATLAB (dynamic, not p.b.o.r), Python (dynamic, p.b.o.r). C# has the unusual feature that some kinds of mutable objects are passed that way while others -- structs -- are passed by value, with the object (in principle) being copied when the call happens.]

Yet, in c# if you do

  int foo(obBob o) { o.x += 1; return o; }
  ...
  Car.x = 3;
  foo(Car);

Then Car.x = 4 which has confused a lot of new programmers. More importantly it's a more consice standard for cube(x) to cube(x) than to say x=cube(x).

Object fields are always passed implicitly by reference (if that makes sense). The value that holds the reference to the object itself is passed by value, unless you specify the "ref" argument modifier (in C#).

For objects, not for builtins such as `int` or `double`. In Clay, when you pass `int a = 3` (or the Clay equivalent) to `increment(a)`, then `a == 4`.

Perhaps for performance? I do think that decision is an awkward one. It fails the principle of least surprise.

The wiki is way more useful than the above link.

https://github.com/jckarter/clay/wiki

Interesting, seems like this would be a good one to include in the recent go/haskell/D/rust shootout.

http://news.ycombinator.com/item?id=6094668

Couldn't find any examples on the claylabs.com page but there is some in the github repo: https://github.com/jckarter/clay/tree/master/examples

It appears that Clay's last released update was over a year ago.

Indeed, but the last commit was 21 days ago. Seems like it's being actively worked on.

Here's a Q&A thread with the creator of Clay, KS Sreeram (a good friend of mine from back in the day): http://www.reddit.com/r/programming/comments/ctmxx/the_clay_...

It's over 3 years old so a lot of it is probably out of date, but still interesting to see the thought process behind the language design.

interesting. are there any hello-world-ish examples around? struggling to find any on the page/wiki.

Found here: https://github.com/jckarter/clay/wiki/Clay-for-C---programme...

    main() { println("Hello world!"); }

That and a few other examples should show up on the homepage or an "examples" page.

Hint for all new language projects going forward: show your Hello World on the front page. A picture is worth a thousand words.

Actually, please do more than just "Hello world", which is not going to show how awesome your language is. Show a few snippets adding up to twenty or so lines of code that illustrate what's different about your language.

good add! show Hello World. plus, show snippets which illustrate what makes your language so special. Why it's worth existing in a world that already has several pre-existing languages and ecosystems to choose from.

Here it is, by the way: https://github.com/jckarter/clay/blob/master/examples/hello.....

Go-lang really killed it on this front.

hehe, sure why not. the more, the better? :)

I was just thinking there hasn't been a new programming language announced in the last week or so. With so few existing languages to choose from that have extensive supporting toolsets and APIs, this will surely stand out.

I feel this is a very insightful comment that adds meaningfully to this discussion. Through the use of cutting and witty satire OP has demonstrated that there is in fact an overabundance of programming languages to choose from with support and tooling, not only stating the obvious, but also serving as a blistering put-down to an individual who worked very hard to provide something useful and did it for absolutely no compensation. Good show sir. I would like to humbly request a subscription to your newsletter.

is it supposed to be obvious how 'clay' is useful? no problem with everyone forking everything and starting yet another language, and it doesn't have to be useful, it can be done for the experience. but if it's advertised, it would be good to explain why?

The OP explains this pretty well. Clay is designed to do generics very concisely and easily.

I'm not sure what you're talking about. The main page language is nice but explains it as much as a job candidates resume header explain what kind of a job candidate he is in a few sentences. There is no comparison to other languages or code examples, there are no success stories that I can see. Maybe they exist, but no, the OP doesn't explain this at all.

Clay wasn't announced this week.

Reply on news.ycombinator.com