perry VS wasmtime

On other sites, like github and reddit. This exchange was funny though. He eventually gets called out by the other commenter to stop responding with an LLM: https://github.com/PerryTS/perry/issues/139#issuecomment-429...

Hey HN — I've been building Perry, a compiler that takes TypeScript and emits native binaries. No V8, no runtime, no Electron. It maps to platform-native UI widgets: AppKit on macOS, UIKit on iOS, Android Views on Android, GTK4 on Linux, Win32 on Windows.

Pry is the first real app built with it — a JSON viewer, deliberately small.

It's in the iOS/macOS App Store and Google Play right now. Linux build works, Windows is waiting on code signing.

The compiler itself is written in Rust. It handles TypeScript parsing, type checking, and lowers to native code. The UI bindings aren't a wrapper library — the compiler generates the actual platform API calls.

This is a building-in-public thing. Pry is the proof-of-concept. The bigger goal is a full IDE. Happy to answer questions about the compiler architecture, the app store submission process, or anything else.

Compiler repo: https://github.com/PerryTS/perry

Hello HN,

For my own needs I needed a powerful WASM engine that provides JIT acceleration, and use it from the convenience of the Swift Package Manager.

So I ended up wrapping wasmtime (a Rust project) https://github.com/bytecodealliance/wasmtime/

The SPM package does support most platforms swift supports, including mobile where JIT is simply not available.

I'd be happy to hear from you if this is something you may be interested in using and what are your WASM use cases.

Thanks :+1:

Every ACT tool is a WebAssembly component running inside wasmtime — a full VM with a JIT, linear memory, and no ambient host syscalls. Out of the box the component has zero filesystem access, zero outbound network, and no way to spawn a process. Each capability it does use (wasi:filesystem, wasi:http) is declared in the component manifest at build time and granted by the operator at run time. The host enforces the intersection: a permissive operator can't escalate past the component's stated intent, a lazy component can't silently exceed the operator's grant. You hand a tool from ghcr.io/someone-else/whatever to your agent, and the worst-case blast radius is still bounded by the policy you wrote.

Cranelift — Production-quality code generator (we’ll reference this)

It's possible to run WebAssembly programs from the command line (without any GUI) using WASI (see e.g. https://github.com/WebAssembly/WASI). Thus if the user downloads pdfconverter.wasi , and the user already has e.g. wasmtime installed, they can run `wasmtime pdfconverter.wasi input.pdf output.pdf` from the command line (see https://github.com/bytecodealliance/wasmtime/blob/main/docs/... for details).

In addition to the web site, the Electron app and the Chrome extension, you may want to distribute a command-line version of your tools as WASI-style .wasm program files. If you do so, I would exclusively use the them this way, from the command line.

Here's where it gets interesting. Plugins are compiled to WASM and run in wasmtime sandboxes. This means:

Upon finishing the initial development of the Smart Escrows implementation and reaching the review and testing stage, the RippleX programmability team decided to revisit the decision on the initial selection of WAMR as our WebAssembly VM runtime, to ensure the chosen runtime is well-positioned for success in our XRPL usage context. The team now had better context on VM internals and a better understanding of WebAssembly in general, which enabled a deeper analysis now compared to when the initial decision was made. Based on some initial meetings with members of the WebAssembly community, the team investigated two alternative runtimes (Wasmi and Wasmtime).

Cranelift does not use copy-and-patch. Consider, for example, this file, which implements part of the instruction generation logic for x64: https://github.com/bytecodealliance/wasmtime/blob/main/crane...

Copy-and-patch is a technique for reducing the amount of effort it takes to write a JIT by leaning on an existing AOT compiler's code generator. Instead of generating machine code yourself, you can get LLVM (or another compiler) to generate a small snippet of code for each operation in your internal IR. Then codegen is simply a matter of copying the precompiled snippet and patching up the references.

The more resources are poured into a JIT, the less it is likely to use copy-and-patch. You get more control/flexibility doing codegen yourself.

But see also Deegen for a pretty cool example of trying to push this approach as far as possible: https://aha.stanford.edu/deegen-meta-compiler-approach-high-...

Sure, but your add-ons will need access to some of the world, which right now requires giving them access to all of WASI, as far as I know. There’s no permissions model. That’s worse than the JVM.

(It seems like they want to implement one… someday. It’s vague: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...)