beariish

I appreciate the followup here. The brainfuck interpreter isn't meant to be a benchmark notably, it's a naive implementation for the sake of the example.

I did spot some poor code in the Bolt version of nbody that can be changed (the usage of `.each()` in the hot loop is creating loads of temporary iterators, that's the memory difference.)

luajit -joff does perform better even with this change, but I observe closer to 15% than a 2x difference

It depends on your exact usecase, I'm not 100% sure what you're asking. There is some overhead for invoking the compiler on a per-script basis. If you're parsing once but running a script many times, Bolt provides some tools (like reusing a preallocated thread object) to ammortize that cost

There's nothing like that right now, but it's absolutely something I want to explore in the future.

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.

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.

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.

Bolt is not compiled ahead of time, it's bytecode interpreted just like Lua

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.

That's a good point, thank you. I've made a small edit to clarify.

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.