kairo

From my personal judgment: definitely using AI for the code & commits, probably for the documentation, no idea about the design. For instance, no human would write this commit message, with the preformatted-code-block: https://github.com/helixlang/helix-lang/commit/4d949efd42b8d...

Really cool to see that LSPs are no longer an afterthought, but rather a core part of the compiler. (evidence: https://github.com/helixlang/helix-lang/blob/21ac6a24ba34ca2...)

This is cool, I think the most novel/unique aspect is the advanced memory tracking: https://github.com/helixlang/helix-lang?tab=readme-ov-file#a... Still, I don't really see this going anywhere. There are already so many "slightly better C++" languages out there, e.g. D, cppfront/cpp2, Carbon, Zig and they pretty much all don't see wider adoption for the same reason. No matter how simple or ergonomic the interop with C++ is, the switching cost is still high and the benefit tends to be marginal. Almost all of them either include garbage collection or don't fully guarantee memory safety. Choosing a restricted subset of C++ and an opinionated, enforced linter & static analyzer goes a long way and gets you most of the benefits of these new languages, so organizations tend to just do that. The exception is Rust, because in spite of all its dow