u/Lord_Mystic12

We posted here as Helix around a year ago.

We took a lot of input into consideration and built on it. The name collided with helix-editor, and as of now, several other things, like Microsoft's new console project. Several technical claims didn't hold up. So rather than a marketing-esque talk, we’ve spent the year doing work. The updates:

• Renamed to Kairo. New repo: github.com/kairolang/kairo. The name Helix with the name-collision of the IDE was pretty bad to say the least...
• Stage 0 (the C++ transpiler) compiles to native binaries on macOS, Linux, and Windows. It's complete and cleanly compiles the entire Stage 1 frontend (~70k lines of Kairo) today. Keeping Stage 0 a transpiler was intentional. The points of Stage 0:
• Prove language feasibility, find gaps in the design and cleanup.
• More concretely avoiding having sema written twice (once in C++, once in Kairo) is wasted work.

All the effort over the past year has been going into stage-1; the compiler frontend is mostly complete, minus full testing and hardening.

The docs are in a far better position than before - real technical docs now exist, while it is all written for what stage-1 can compile, it goes into quite a bit of detail about technical implementation, there might be some drift between the pages - since things are being edited and reworded constantly, but most of what's there is frozen until stage-1 ships with the full language feature set.

Compiler dev-wise, here's where everything is so far:

• Lexer: Full Unicode support, f-strings, nested comments, git conflict marker detection. ~150 MB/s throughput, tested on an AMD Ryzen 9 9950X3D2 (1000 runs, 5MB input, warm cache).
• Preprocessor runs a three-phase wave, parallelized by a custom threading runtime. ~85 MB/s, same testing base as above
• Parser: The parser is still undergoing correctness tests; performance benchmarking will follow. Parser design uses CRTP-Mixins, arena allocation, context switching, tentative guards, sync sets, and non-cascading recovery.
• GlobalHoistedScope is a thread-safe, pre-parse symbol table for concurrent multi-TU indexing.
• Driver: calls into LLVM's actual C++ API via kairo's FFI model What is not done:
• AMT (ownership/borrow checker) is designed and planned conceptually, but not implemented, and won't be till stage2.
• Stage 1's Sema, and Lowering Passes.
• Codegen.

Estimated time till a working stage-1 alpha where some of Kairo's features compile into runnable/linkable artifacts is, EOY 2026

The one gap Kairo is actually built to close: full native C++ interop, templates and concepts included, no binding layer, no generated shim. ffi "c++" import parses the header and the C++ symbols become native Kairo symbols. This isn't a goal, it's the thing the compiler's own driver runs on today. Here's a stripped-down piece of the stage-1 driver's runtime init, compiling on stage-0 right now, it pulls real LLVM types straight from LLVM's headers:

ffi "c++" import "llvm/Support/InitLLVM.h"
ffi "c++" import "llvm/Support/Locale.h"
        
fn init_runtime(argc: i32, argv: *(*kairo::std::Legacy::char)) {
    // things like kairo::std::Legacy::char are stage-0 types, stage-1 cleans up the type system and removes things like this...
    static var init_llvm = llvm::InitLLVM(argc, argv)
        
    llvm::setBugReportMsg(
        r"PLEASE submit a bug report to https://github.com/kairolang/kairo/issues..."
    )
}

You can read the real driver code here. Kairo's philosophy:

Kairo is grounded by a simple idea: Give developers full control without forcing them to fight the language, or put more cleanly "safety through visibility, not restriction"

Four core points drive every language design decision in Kairo:

• "Fine grained control should exist". The language should expose the underlying system in a way that lets developers choose how to use it, but they should also be able to ignore it if they don't need to.
• "Safety should assist, not dominate". The reason for this is safety should only be a tool to help developers, not a restrict productivity; The plan for the AMT is to warn in debug, and hard error in release, crucially the error message matters too, Kairo would not just say "you are doing something unsafe", it would say the why, where, and what debug would change to make it safe.
• "Code should always be self documenting all costs". The compiler shouldn't add branching where not asked for; it shouldn't unwind tables for exceptions, etc. This comes back to all code being self-documenting; things like unwinding should be explicitly typed out and requested by the programmer.
• "Adoption should be incremental". We know most devs aren't going to switch to a new language and migrate thousands of lines of code just 'cause it does... they want to migrate incrementally, one system at a time, testing it and moving to the next. Hence, full native C++ interop.

The README links to a transparent disclosure of AI use, describing what AI was and was not used for. TL;DR: compiler code, compiler architecture, language design, all human. Docs prose polish only - technical content is human, commit messages (gitlens) and website were AI-assisted. No one in the team does web design, if you have experience and want to make our website better please pm.

Mostly posting here, for feedback and genuine thoughts; especially the AMT model, FFI, basically anything about the language, or even cases you might use Kairo for. Happy to discuss anything in comments.

If you have criticism, state it - it helps us improve and learn; If you have praise, state it - it helps us know what we are getting right and what to keep doing.

Kairo - the idea - is only about 2 years old, and the compiler is only about a year old, we are still learning and growing.

• Repo: github.com/kairolang/kairo
• Website: kairolang.org
• Docs: kairolang.org/docs

If Kairo's interesting, a github star helps us gauge whether public progress posts are worth the time over heads-down work.

Quick notice : there will be two people replying to all comments here , me and another co dev of mine u/Ze7111

New to this game, holy fuck yuzuriha is overpowered

I got thru the 3 arrow challenges by just button mashing , thought it's not really necessary, but wtf is this .

This is also my first proper fighting game, I've religiously played brawlhalls and smash for the last 5 years and found this cos of the soundtrack and bought it cos it was on sale

Better quality on my X : https://x.com/chaos_theartgod/status/2063062515446092191?s=20

been a year since i finished the game, finally made some fanart

Higher quality on my twitter :

https://x.com/chaos_theartgod/status/2060855553316770177

Fairly certain the green bounced off the red

Yes it's a bit rough, had to work with the ds stylus .

As an fyi, my only other exposure is studying up on anime animators and doing semi professional illustrator work