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.
I'm doing this because it interests me and I'm learning, but it does feel quixotic at times.