This is really cool but it's not portable to MacOs or aarm64 yet, and that kind of portability unfortunately is what appeals to me about an embeddable scripting language.
Show HN: Bolt – A super-fast, statically-typed scripting language written in C
41–50 of 98 posts
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#42This 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.
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
We have a server which uses Lua based script plugins. They are usually a few hundred to a few thousand lines and get invoked via APIs. I was trying to figure out how Bolt will behave in such a context and whether we could replace the Lua based plugin engine with this.
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#43Function 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.
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.
Ah, true, now that you mention it. I feel like it's the best of both worlds, you get type inference and it gets documented automatically.
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#44Outperforming languages in its class is doing some heavy lifting here. Missing comparison to wasm interpreter, any of the java or dot net interpreters, the MLs, any lisps etc.
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.
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#45Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#46I 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…
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.
Or: `import math with abs as absolute, sqrt as square_root`
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#47I was quite excited by the description and then I noted that Bolt heavily relies on double floating point numbers. I am quite disappointed because this doesn't allow me to use Bolt in my context: embedded systems where floating point numbers are rarely supported... So I realized that I misinterpreted `embedded`.
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#48Outperforming languages in its class is doing some heavy lifting here. Missing comparison to wasm interpreter, any of the java or dot net interpreters, the MLs, any lisps etc. 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, dep…
The class is "embeddable interpreted scripting language", which is not quite the same thing as just an interpreter.
Embedded interpreters are that designed to be embedded into a c/c++ program (often a game) as a scripting language. They typically have as few dependencies as possible, try to be lightweight and focus on making it really easy to interopt between contexts.
The comparison hits many of the major languages for this usecase. Though it probably should have included mono's interpreter mode, even if nobody really uses it since mono got AoT
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#49I 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.
From my research into the subject the easiest way to implement it would be a 'musttail' macro which falls back to a trampoline for compilers which don't support it. The problem then becomes having the function call overhead (assuming the compiler can't figure out what's going on and do tail-call optimizations anyway) on the unsupported systems with each and every opcode which is probably slower than just a Big Old Switch -- which, apparently, modern compilers are pretty good at optimizing.
The VM I've been poking at is I/O bound so the difference (probably) isn't even measurable over the overhead of reading a file. I went with a pure 'musttail' implementation but didn't do any sort of performance measurements so who knows if it's better or not.
Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C
#50In terms of performance, how does it compare to compiled languages like the C it’s written in?