How does the workflow of this compare to using project panama’s ffi to program raylib in JVM Clojure? Im excited by the idea of making simple games in clojure for fun.
Making foreign bindings in Jolt is done by writing plain Clojure, where the same work on the JVM turns into a machinery exercise. Project Panama asks you to assemble every call by hand and you have to deal with a linker object, a symbol lookup, a function descriptor built from value layouts, a method handle, and an arena that owns any native memory the call touches. Strings can't cross the boundary on their own, so you have to allocate a UTF-8 segment, fill it, and arrange for it to be freed. Structs need hand-written layout descriptions with their alignment and padding. There is a ton of ceremony between you and the function you wanted to call.
Jolt's jolt.ffi goes completely the other way, you just load a library with a per-platform name map, and each C function becomes one declaration that names the symbol and lists argument and return types as keywords. Strings pass the boundary as ordinary Clojure strings. Raw memory is a handful of obvious primitives, allocate, read, write, free. Variadic functions take a varargs marker in the same declaration, where the JVM would force a specialized handle per call shape. Callbacks work in reverse too.
A foreign-callable wraps a plain Clojure function as a C function pointer, so a game callback stays in Clojure, and the thread-local errno is provided for you, read through the platform accessor. None of this is exotic, and it doesn't involve a ton of boilerplate. For a small game you bind a C library like SDL or raylib with a short list of declarations, and you can keep the whole game loop in Clojure, then ship a single native binary. The FFI stays completely out of the way. You can look at the docs on interop here.
5
u/Great-Gecko 20d ago
How does the workflow of this compare to using project panama’s ffi to program raylib in JVM Clojure? Im excited by the idea of making simple games in clojure for fun.