6 ms·

No, they are actually real executables without the need of an external runtime. You can get images also if you like. See quickbin in the jpm man page. > Crea

No, they are actually real executables without the need of an external runtime. You can get images also if you like. See quickbin in the jpm man page. > Create a standalone, statically linked executable from a Janet source file that contains a main function. and discussion here https://janet.guide/ https://janet.guide/ > 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.

packetlost 1y ago
No, gp is correct, the 'real executables' are a VM image with the interpreter baked in. The only native code in the binary is the interpreter. Janet code does not compile to machine code.
- terminalbraid 1y ago
  I understand your point, but by similar logic I can argue any language is interpreted because nothing compiles down to microcode. The point is you don't need janet-specific external dependencies in the environment. I don't differentiate between this and an inefficient compiler.
  - xigoi 1y ago
    The distinction matters because the resulting executable is not (significantly) faster than running the program as a script.
    - massung 1y ago
      I think the distinction (from the OP’s perspective) is that it’s “just an app” to the end user. 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.
  - packetlost 1y ago
    > I can argue any language is interpreted because nothing compiles down to microcode 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.
xigoi 1y ago
From the book you linked: > 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. https://janet.guide/compilation-and-imagination/ https://janet.guide/compilation-and-imagination/
- fuzztester 1y ago
  So after all those steps, it is actually compiled native code that you run?
  - xigoi 1y ago
    Yes, but the code portion of the executable is really the Janet interpreter, while your code lives in the data segment and is not in the native form.
- veqq 1y ago
  Tangentially, image-based development is possible, reloading images into the REPL for more interesting workflows: https://alexalejandre.com/notes/exploring-janet/#image-based-development https://alexalejandre.com/notes/exploring-janet/#image-based... but it's a WIP.

packetlost 1y ago

No, gp is correct, the 'real executables' are a VM image with the interpreter baked in. The only native code in the binary is the interpreter. Janet code does not compile to machine code.

terminalbraid 1y ago
I understand your point, but by similar logic I can argue any language is interpreted because nothing compiles down to microcode. The point is you don't need janet-specific external dependencies in the environment. I don't differentiate between this and an inefficient compiler.
- xigoi 1y ago
  The distinction matters because the resulting executable is not (significantly) faster than running the program as a script.
  - massung 1y ago
    I think the distinction (from the OP’s perspective) is that it’s “just an app” to the end user. 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.
- packetlost 1y ago
  > I can argue any language is interpreted because nothing compiles down to microcode 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.

xigoi 1y ago

From the book you linked: > 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. https://janet.guide/compilation-and-imagination/ https://janet.guide/compilation-and-imagination/

fuzztester 1y ago
So after all those steps, it is actually compiled native code that you run?
- xigoi 1y ago
  Yes, but the code portion of the executable is really the Janet interpreter, while your code lives in the data segment and is not in the native form.
veqq 1y ago
Tangentially, image-based development is possible, reloading images into the REPL for more interesting workflows: https://alexalejandre.com/notes/exploring-janet/#image-based-development https://alexalejandre.com/notes/exploring-janet/#image-based... but it's a WIP.