[HN Gopher] Show HN: Bolt - A super-fast, statically-typed scrip...
___________________________________________________________________
Show HN: Bolt - A super-fast, statically-typed scripting language
written in C
I've built many interpreters over the years, and Bolt represents my
attempt at building the scripting language I always wanted. This is
the first public release, 0.1.0! I've felt like most embedded
languages have been moving towards safety and typing over years,
with things like Python type hints, the explosive popularity of
typescript, and even typing in Luau, which powers one of the
largest scripted evironments in the world. Bolt attempts to
harness this directly in the lagnauge rather than as a
preprocessing step, and reap benefits in terms of both safety and
performance. I intend to be publishing toys and examples of
applications embedding Bolt over the coming few weeks, but be sure
to check out the examples and the programming guide in the repo if
you're interested!
Author : beariish
Score : 110 points
Date : 2025-08-10 17:53 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| themonsu wrote:
| Looks cool, but please can we stop naming things "bolt"
| IAmLiterallyAB wrote:
| Yeah this is the third programming language named Bolt that I'm
| aware of
| acron0 wrote:
| If I was still writing games I would be alllllll over this
| grodriguez100 wrote:
| Sounds very good, and I can see many use cases in embedded
| systems. But that probably requires 32-bit arm support. Is that
| planned ?
| beariish wrote:
| As of right now no - my primary target when developing this was
| realtime and games in particular since that's what I know best,
| but if there's a real target in embedded that's certainly
| something that could be explored.
| MobiusHorizons wrote:
| FYI "the embedded scene" is likely to be interpreted as "embedded
| systems" rather than "embedded interpreters" even by people who
| know about embedded interpreters, especially since all the
| languages you give as an example have been attempted for use on
| those targets (micropython, lua, and even typescript)
| beariish wrote:
| That's a good point, thank you. I've made a small edit to
| clarify.
| thrance wrote:
| Function return type inference is funny but I don't think it's
| that great of a feature. It makes it harder for a library's
| consumer to know how to properly use a function, and it also
| makes it harder for the maintainer to not break backwards
| compatibility inadvertently. Anyway, I'm all for experimenting.
| beariish wrote:
| There's nothing stopping a library author from explicitly
| annotating return types wherever a stable interface is
| important, the idea is more for smaller functions or callbacks
| to make use of this. Perhaps I'll make the examples clearer to
| reflect the intention.
| jitl wrote:
| It's great in TypeScript. In TypeScript your source can have
| inferred types returned, and then use a build step to produce
| resolved typings files (.d.ts) for distribution that have the
| fully specified type.
| eulgro wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| 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
| brabel wrote:
| 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.
| cookiengineer wrote:
| 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
| zygentoma wrote:
| Oh, not OP, but I love Koka. I should play around with it again
| thanks for reminding me!
| driggs wrote:
| > If functions don't have a return signature, does that mean
| everything must be satisfied in the compilation step?
|
| Functions _do_ have a return signature.
|
| It looks like the author chose to show off the feature of
| return type inference in the short example README code, rather
| than the explicit case.
|
| https://github.com/Beariish/bolt/blob/main/doc/Bolt%20Progra...
| Vandash wrote:
| game dev for 15+ years here, love the first example on Github
| this is compiled right? cannot replace lua?
| beariish wrote:
| Bolt is not compiled ahead of time, it's bytecode interpreted
| just like Lua
| IshKebab wrote:
| It's compiled in the same way that Lua is compiled. So yes, it
| can replace Lua.
| kiririn wrote:
| Nice, gives me Pawn vibes
|
| (https://www.compuphase.com/pawn/pawn.htm)
| haberman wrote:
| 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...
| beariish wrote:
| 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.
| summerwant wrote:
| I see lua, do you know terralang?
| debugnik wrote:
| You may be interested in Luau, which is the gradually-typed
| dialect of Lua maintained by Roblox. The game Alan Wake 2 also
| used it for level scripting.
| perlgeek wrote:
| 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 p } from "./maths.js";t
| beariish wrote:
| Do you think approaching the way typescript does it for Bolt is
| a reasonable compromise here? Bolt already supports full-module
| renames like import math as not_math
|
| So supporting something along the lines of
| import abs as absolute, sqrt as square_root from math
|
| Would be farily simple to accomplish.
| bbkane wrote:
| I really like the way Elm does it, from "wide" (package) to
| "narrow" (symbol). I suspect this also helps language server
| implementation.
|
| See https://guide.elm-lang.org/webapps/modules (scroll down to
| "Using Modules") for examples
| jasonjmcghee wrote:
| Also autocomplete.
|
| Though I almost never manually type out imports manually
| anymore.
| vhodges wrote:
| According to the Programming Guide, it supports aliases for
| imports
|
| "In case of conflict or convenience, you can give modules an
| alias as well."
| Fraterkes wrote:
| Really cool! Roughly how much memory does it take to include it
| in an engine? Also I'm really interested in the process of
| creating these really fast scripting languages, have you written
| anything about how you wrote Bolt?
| beariish wrote:
| Bolt's memory usage in most cases hovers right around Lua
| 5.4/Luau in my own testing, but maybe I should include a few
| memory benchmarks to highlight that more. It does notably have
| a higher memory overhead during compilation than other
| languages in this class though.
|
| As for writeups, I'm working on putting out some material about
| the creation of Bolt and my learnings now that it's out there.
| Forgret wrote:
| It looks cool, I wish you luck in developing the language. I
| liked your language and I hope it becomes popular someday.
| freeopinion wrote:
| I see your benchmarks compare against other interpreted languages
| "in its class".
|
| 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.
| k__ wrote:
| Awesome.
|
| Is it deterministic like Lua?
| astatine wrote:
| This looks awesome. Would you have any data on the performance of
| large number of invocations of small scripts? I am wondering at
| startup overhead for every script run. which the 500kloc/s may
| not capture well.
| memophysic wrote:
| Looks great, I'm especially a fan of the more C and Python
| syntax. Lua works, but its syntax has always been bugging me.
|
| On the feature side, is there any support for breakpoints or a
| debugging server, and if not is it planned?
___________________________________________________________________
(page generated 2025-08-10 23:00 UTC)