Looks cool, but please can we stop naming things ”bolt”

If I was still writing games I would be alllllll over this

Sounds very good, and I can see many use cases in embedded systems. But that probably requires 32-bit arm support. Is that planned ?

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)

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.

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.

game dev for 15+ years here, love the first example on Github this is compiled right? cannot replace lua?

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

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?

It looks cool, I wish you luck in developing the language. I liked your language and I hope it becomes popular someday.

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.

Awesome.

Is it deterministic like Lua?

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.

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?

Congrats! I think this could be quite useful for me.

I noticed that `let`-declared variables seem to be mutable. I'd strongly recommend against that. Add a `var` keyword.

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.

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

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

In terms of performance, how does it compare to compiled languages like the C it’s written in?

Nice language! I am wondering how error handling / exceptions works in bolt?

Quickly scanned the programming guide - but wasn't able to find it. Did i miss a section?

Wow a fast scripting language with normal syntax and type checking.. Really hope this can take off and be a valid Lua alternative.

I might be missing this, but I'm not seeing anything about how the type system handles (or doesn't) polymorphism - generics, traits, that sort of thing. Is that in there?

This looks so familiar that it got me thinking: who is collating all of the languages that are being invented? I must see two dozen a year on HN. I'm not dissing OP, but I've seen so many languages I'm not sure if I'm having deja vu, or vuja de.

Run some examples, and it looks like this "High-performance, real-time optimized, super-fast" language is

  ~ 10 times slower than luajit
  ~ 3 times slower than lua 5.4

Looks nice! Is there any plans on a language server and formatting tooling?

Usually I feel like that's bare minimum before I'd like to try and play around with a language