[nl]

This seems either wrong or very uncharitable.

> Perry exposes a faithful subset of Node.js’s stdlib HTTP server modules on top of hyper + rustls + tokio-tungstenite. The whole shape — handler signature, IncomingMessage / ServerResponse properties + methods, TLS opts, ALPN-negotiated HTTP/2, WebSocket upgrade dispatch — works unmodified, so unmodified Node servers (Express / Koa / Polka / hono via @hono/node-server / etc.) compile and run natively[1]

It's pretty standard for "no runtime" to mean nothing on the device you install the compiled target app.

I think iOS development still needs Ruby for Pod installation but no one says Swift apps need a Ruby runtime for example.

[1] https://docs.perryts.com/stdlib/http.html

[ventana]

Well, I did indeed spend some time playing with it before writing my comment. I first tried to compile the TypeScript project I'm working on, and it happens to be an Express server. After some minor unrelated fixes required (Perry does not understand importing "fs/promises", so I fixed it to import "fs" and then taking .promises) it said it needs JS runtime, and the smallest repro I found was

  $ cat index.ts
  import * as express from 'express';
  const app = express();

which gives

  $ perry index.ts
  Collecting modules...
    JS module: express -> /private/tmp/ex/node_modules/express/index.js
  Error: build pulled in `perry-jsruntime` (QuickJS-based eval-equivalent runtime)   via the following file(s):
    - /private/tmp/ex/node_modules/express/index.js [express]
  
  `perry-jsruntime` is treated as a privileged dependency on par with adding a JIT to the binary — it re-introduces arbitrary runtime code execution and defeats Perry's structural advantage over Node. Refusing to link by default. (#499)
  
  To enable, set `perry.allowJsRuntime: true` in the host package.json, or pass `--enable-js-runtime` on the CLI for a one-off build. (Falls under `--lockdown` deny set when that flag ships — see #496.)

Maybe it's because Express is written in JavaScript with external types from @types/express, that would explain why it might need JS runtime, but it does not make things easier for me.

[nl]

Fair, but might have been worth including that in your initial comment because the docs don't mention that at all.

[interstice]

I got the impression from the first comment that it was speaking from experience not the docs

[ozgrakkurt]

It is not standard for “no runtime” to mean that. For example go has a runtime that is compiled into the binary or you can google c runtime and see a million ways the word “runtime” is used with c.

[pjmlp]

> It's pretty standard for "no runtime" to mean nothing on the device you install the compiled target app.

Only by layman that don't understand compilers.

[lkirkwood]

The tone here is a bit rude but I'm still curious: what does no runtime mean to you?

[pjmlp]

It is my tone, GenX, no minced words.

The infrastructure required to support a programming language, startup and shutdown boilerplate, all the required functionality to support standard library features including integration points between language semantics and support code.

Stuff like what code runs before and after main(), trap handlers for floating point arithmetic, handling of thread local storage, bind language heap handling primitives to library code, traps for handling stack overflow errors,....

[wren6991]

Right, runtime is so broad that it's hard to say something has "no runtime". libgcc + your choice of crt0 is a C runtime, and the JVM is a Java runtime. That's a huge spectrum.

It's worth being charitable in your interpretation though and recognising "no runtime" probably refers to JVM-shaped or Node-shaped things, not libgcc+crt0-shaped things.

[Rohansi]

Alternatively, "runtime" is a derogatory term used by programmers who want to show superiority over others who use languages with more (built-in) features than theirs.

There's practically no difference for the overwhelming majority of software these days. Most people aren't working on embedded systems or operating systems.