Polyglot Programming through Foreign Function Interfaces
summary
Argues that raw FFIs cause subtle semantic bugs (Ruby callers copy Python examples and mis-evaluate keyword args or dict syntax) and proposes code migration via an embedded-DSL approach using a small refi primitive that turns lambdas into ASTs so host code runs with guest semantics. Builds a Ruby–JavaScript bridge, detects cyclic leaks from cross-process callbacks, and solves them by copy reference graph plus a send barrier and incremental sync; solution works for few remote refs but hits modern-GC edge cases.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:10Polyglot programming essentials
- 5:31Polyglot with VMs and FFI
- 7:24FFI pitfalls in practice
- 16:29FFI wrong abstraction?
- 19:32Code migration proposal
- 25:45Memory challenges in polyglot
- 31:30Ruby and JS memory managers
- 45:55Summary and future
- 48:27Q&A: WebAssembly vs JVM
- 50:39Q&A: Modifying VMs for memory management
- 54:13Q&A: High-level to low-level
- 55:41Q&A: Large-scale costs
- 57:50Q&A: Syntax and LLM limits
related talks
01h 05mAll the Languages Together
48mCalling Functions Across Languages
21mSecurely Compiling F* Programs With IO and Then Linking Them Against Weakly-Typ...
41mAn Introduction to Functional Imperative Programming in Flix
20mFluent APIs in Functional Languages
44mRethinking compilers with live coding
42mFunctional interpreters and you
33mThe Language of the Language: Comparing compiler construction in Clojure and F#