Just keep in mind that these executables are the Janet bytecode interpreter bundled with your bytecode, not “real” native executables.
> Create a standalone, statically linked executable from a Janet source file that contains a main function.
and discussion here
> My favorite feature of Janet, though, is something that sounds really dumb when I say it out loud: you can actually distribute Janet programs to other people. You can compile Janet programs into statically-linked native binaries and give them to people who have never even heard of Janet before. And they can run them without having to install any gems or set up any virtual environments or download any runtimes or anything else like that.
They're not super tiny, though. A hello world I just did is about 727K.
When I download the Slack desktop app, I might know it’s running on electron because I’m a programmer. But I didn’t have to download and install nodejs or anything else. As far as I’m concerned it’s a completely self contained application.
The end user needn’t download and install Janet or even know that Janet exists.
That can obviously be done with any interpreted language, but Janet makes it really simple out of the box.
Not every processor architecture uses microcode, so this doesn't hold up.
> The point is you don't need janet-specific external dependencies in the environment
Sure.
> I don't differentiate between this and an inefficient compiler
A compiler is the general term here, but the target is not. Targeting the native architecture for a CPU vs targeting a bytecode VM are quite different and have pretty important implications for performance, portability, memory usage, etc.
> But in order to produce native code, jpm actually:
> 1. Compiles your Janet source code into an “image.”
> 2. Embeds the contents of that image into a .c file that also links in the Janet runtime and interpreter.
> 3. Compiles that .c file using your system’s C compiler.