My main concern about a new language is not performance, syntax, or features, but long term support and community.

What about memory management/ownership? This would imply that everything must be copy by value in each function callsite, right? How to use references/pointers? Are they supported?

I like the matchers which look similar to Rust, but I dislike the error handling because it is neither implicit, and neither explicit, and therefore will be painful to debug in larger codebases I'd imagine.

Do you know about Koka? I don't like its syntax choices much but I think that an effect based error type system might integrate nicely with your design choices, especially with matchers as consumers.

[1] https://koka-lang.github.io/koka/doc/index.html

(https://www.compuphase.com/pawn/pawn.htm)

I also love the focus on performance. I'm curious if you've considered using a tail call design for the interpreter. I've found this to be the best way to get good code out of the compiler: https://blog.reverberate.org/2021/04/21/musttail-efficient-i... Unfortunately it's not portable to MSVC.

In that article I show that this technique was able to match Mike Pall's hand-coded assembly for one example he gave of LuaJIT's interpreter. Mike later linked to the article as a new take for how to optimize interpreters: https://github.com/LuaJIT/LuaJIT/issues/716#issuecomment-854...

Python 3.14 also added support for this style of interpreter dispatch and got a modest performance win from it: https://blog.reverberate.org/2025/02/10/tail-call-updates.ht...

> import abs, epsilon from math

IMHO it's wrong to put the imported symbols first, because the same symbol could come from two different libraries and mean different things. So the library name is pretty important, and putting it last (and burying it after a potentially long list of imported symbols) just feels wrong.

I get that it has a more natural-language vibe this way, but put there's a really good reason that most of the languages I know that put the package/module name first:

    import packageName.member; // java
    from package import symbol; # python
    use Module 'symbol'; # perl
    

    import { pi as π } from "./maths.js";t

We read here a couple days ago about Q which is compiled. Bolt claims to "plow through code at over 500kloc/thread/second". Q claims to compile in milliseconds--so fast that you can treat it like a script.

Bolt and Q are both newborns. Perhaps you could include each other in your benchmarks to give each other a little publicity.

Is it deterministic like Lua?

On the feature side, is there any support for breakpoints or a debugging server, and if not is it planned?

I noticed that `let`-declared variables seem to be mutable. I'd strongly recommend against that. Add a `var` keyword.

Compile to register bytecode is legitimate as a strategy but its not the fast one, as the author knows, so probably shouldn't be branding the language as fast at this point.

It might be a fast language. Hard to tell from a superficial look, depends on how the type system, alias analysis and concurrency models interact. It's not a fast implementation at this point.

> This means functions do not need to dynamically capture their imports, avoiding closure invocations, and are able to linearly address them in the import array instead of making some kind of environment lookup.

That is suspect, could be burning function identifiers into the bytecode directly, not emitting lookups in a table.

Likewise the switch on the end of each instruction is probably the wrong thing, take a look at a function per op, forced tailcalls, with the interpreter state in the argument registers of the machine function call. There's some good notes on that from some wasm interpreters, and some context on why from luajit if you go looking.