They have an interactive mode right now (crystal i), but it's not very comprehensive. You cannot use certain libraries with it etc.
Shouldn't be terribly hard to make it good though. Some time ago, I added a JIT REPL in a few afternoons with Claude, ending up with roughly the same performance as their compiler, and with it working reliably with all the libraries I tested. But since they don't want LLM contributions in Crystal, I just left it as an interesting experiment and started working on my own language instead.
Crazy how easy it is these days, isn't it? The last 20% that matters is gonna be a bit harder though, I assume. Plus with everybody being able to do it means that making yours be interesting is going to be extra difficult.
It is a lot easier, but I've been working on this language project for almost 8 months now. I've spent a lot of time in research papers and thinking about both dev UX and how it works with LLMs. Knocking together a working compiler on LLVM is WAY easier now, but making something nice is still hard. A language is so much more than a compiler and syntax. So to your point, standing out is incredibly hard.
I'm doing this because it interests me and I'm learning, but it does feel quixotic at times.
Cool. I'm about 3-4 months in, this is the current result: https://hanki-lang.org/docs/reference/ -- sorry about the LLM smell. I haven't paid much attention to making the documentation beautiful yet.
Seems like you're slightly more ambitious with the features (linear typing, refinement typing are way beyond what I dream about). I'm focusing more on a small practical application language with ruby-like aesthetics.
I wanted Hanki to be a general-purpose language that could be used with minimal compromises as a scripting language, a configuration language and a reasonably high-performing application / server-side language. I wanted a good REPL, arbitrary precision arithmetics by default, reasonable safety features (effects, strong typing, concurrency via message-passing actors, erlang-like supervising) and excellent readability for human reviewing.
I wanted to include features that force AI agents into a style, so the linter is included as part of the checker and every linter complaint is an error.
The implementation is currently 300K+ lines of Rust, about 60Kloc of Hanki.
I still have about a hundred beads tickets to go through before I'm happy enough about this that I dare to publish it. And seems like every solved task gets 2 follow-ups :)
That's a cool project! It's fascinating that we both landed on efect-y capabilities with a faile closed system `hanki run --deny io` in hanki and `forge cap inspect ./build/myapp --deny IO.Network`[1] for binary audits in March. In general though March requires a compiled program to declare it's needs and errors on undeclared IO, etc.[2]
This is super interesting, I really like it. Actor concurrency with effects is not as broadly implemented as it should be.
Shouldn't be terribly hard to make it good though. Some time ago, I added a JIT REPL in a few afternoons with Claude, ending up with roughly the same performance as their compiler, and with it working reliably with all the libraries I tested. But since they don't want LLM contributions in Crystal, I just left it as an interesting experiment and started working on my own language instead.