Live data from Hacker News

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

github.com

11–20 of 98 posts

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

#11
post #10

The question I ask myself when I see this kind of project is: how long are you willing to maintain it for? My main concern about a new language is not performance, syntax, or features, but long term support and community.

In the end, weight is a kind of strength, and popularity is a kind of quality. It looks promising but you can't expect long-term support until there's more contributors and users

At this point it is too early to know. Even JavaScript took like 20 years to catch on

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

#12
If functions don't have a return signature, does that mean everything must be satisfied in the compilation step?

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

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

#14
post #10

The question I ask myself when I see this kind of project is: how long are you willing to maintain it for? My main concern about a new language is not performance, syntax, or features, but long term support and community.

The only way to have any idea of how long a language might be still around is to look at how long it's been already around. From this perspective , you can only use older languages. The benchmarks show that Lua (and the Luau and Lua+JIT variants) is actually very competitive, so I'd stick with one of those.

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

#18
I love the concept -- I've often wished that lean languages like Lua had more support for static typing, especially given the potential performance benefits.

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

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

#19

I love the concept -- I've often wished that lean languages like Lua had more support for static typing, especially given the potential performance benefits. 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... Unfortun…

I did experiment with a few different dispatch methods before settling on the one in Bolt now, though not with tailcalls specifically. The approach I landed on was largely chosen cause it in my testing competes with computed goto solutions while also compiling on msvc, but I'm absolutely open to try other things out.

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

#20
I like 99% of this, and the thing I don't like is in the very first line of the example:

> 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
    
With Typescript being the notable exception:

    import { pi as π } from "./maths.js";t
Post reply on HN