Show HN: Bolt – A super-fast, statically-typed scripting language written in C

> 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

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...

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)

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