3 ms·

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

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