4 ms·

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/jck

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/jckarter/Vinyl - https://github.com/Blei/claytracks 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.

dottrap 13y ago
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.
- moomin 13y ago
  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.
- mratzloff 13y ago
  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.
tezka 13y ago
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.
- mratzloff 13y ago
  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-reference.md#patternguards https://github.com/jckarter/clay/blob/v0.1.0/doc/language-re...

dottrap 13y ago

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.

moomin 13y ago
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.
mratzloff 13y ago
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.

tezka 13y ago

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.

mratzloff 13y ago
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-reference.md#patternguards https://github.com/jckarter/clay/blob/v0.1.0/doc/language-re...