nimscripter VS zig

> What does this mean? There's a runtime VM or compile time VM?

Compile time VM. It's used to run macros / templates / concepts. You can also run most code at compile time in a `static` block except for stuff that needs C calls. You can also compile the VM into a program and use it as a runtime VM (see https://github.com/beef331/nimscripter) which I do in my GUI lib. NIR should enable the compile time VM to run faster too, and possibly use JIT'ed code.

Checkout Nim! It does much of what you describe and its great. The core language is fairly small (not quite lua simple but probably ML comparable). It compiles fast enough that a Nim repl like `inim` is useable to check features and for basic maths, though it requires a C compiler, but TCC [4] works perfectly. Essentially Nim + tcc is pretty close to your description, IMHO. Though I'm not sure TCC supports non-x86 targets.

I've never used it but Nim does support some hot reloading as well [3]. It also has a real VM if you want to run user scripts and has a nice library for it [1]. Its not quite Lua flexible but for a generally compiled language its impressive.

Recently I made a wrapper to embed access to the Nim compilers macros at runtime [2]. It took 3-4 hours probably and still compiles in 10s of seconds despite building in a fair bit of the compiler! It was useful for making a code generator for a serializer format. Though I'm not sure its small enough to live on even beefy m4/m7 microcontrollers. Though I'm tempted to try.

1: https://github.com/beef331/nimscripter

It's "Zig" not "Zag". https://ziglang.org/ Zig is under heavy development, but there's a single page https://ziglang.org/documentation/0.12.0/ that is a reasonably comprehensive source of truth about the current state of the language.

There is an issue proposing this approach: https://github.com/ziglang/zig/issues/4284

https://github.com/ziglang/zig/issues/224

e.g.:

> > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g.

When writing code in a scripting language, sometimes you need that extra bit of performance (or maybe an async feature from Zig).

NodeJS is by no means a slow runtime, it wouldn’t be so popular if it was. But compared to Bun, it’s slow. Bun was built from the ground up with speed in mind, using both JavascriptCore and Zig. The Bun team spent an enormous amount of time and energy trying to make Bun fast, including lots of profiling, benchmarking, and optimizations.

ntdll.dll!RtlUserThreadStart()

There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.

https://github.com/ziglang/zig/issues/11894