Hacker Newsnew | comments | show | ask | jobs | submit login

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

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: