Hacker News Reader

Comment by dustingetz | Hacker News Reader

the Arcadia team spent several years on this hypothesis, I am not sure the idea of a Clojure REPL for gamedev is free of impedance mismatches

View on HN

Arcadia's biggest drawback was that it was dependent on Unity, which meant that it had all of the issues that Unity had plus some new ones. Without source code access it's difficult to exceed the features/performance of the base engine.

Maybe they've fixed some stuff (or ported it it Godot) since I last checked it, but the general lack of editor support, the clash between how Unity wanted to operate and how Clojure wanted to work, and usual Unity problems kept me from building anything significant in it.

I'm curious how this would go with something like Janet that is much simpler to interface with C++.

AFAIK Janet is not "much simpler to interface with C++". Janet has good FFI for C, but not for C++ directly. Janet's native FFI system is designed specifically for C libraries. C++ has name mangling, classes, exceptions, and other features that Janet's FFI cannot directly handle. The process would be similar to using C++ libraries from any C-based language, which is far from straightforward.

Jank, if my understanding is correct, in comparison has direct C++ interop. Jank treats C++ as a first-class compilation target rather than a foreign interface.

It shouldn't be that much work to wrap a C interface into C++ but yeah Jank is probably the way to go if it natively supports C++.

Yeah, well, I don't think it's that simple. You can't just say "eh, gamedevs apparently just don't want 'interactive workflows'", which of course, not true - look at Unreal's Blueprint live editing, Unity's play mode value tweaking, Godot's live scene editing, Jonathan Blow live-coding an entire game, etc.

I don't know why Arcadia wasn't very successful -I have never used it; I can only speculate on the causes, but I have good reasons to believe that Jank may actually succeed where Arcadia struggled - it is designed ground-up for game engine integration, no GC pauses, better FFI for engine bindings, etc.

the request/response command/query nature of the REPL is what I am referring to. Great fit for RPC-oriented web backends backed by OLTP databases that start fresh each time and run to completion. Live scene editing seems closer in nature to a hot module reloading workflow, where we try to take care not to disturb long-lived objects and processes. PS, Jank is very cool. No idea what his plans are here and I’m not claiming a gamedev repl is impossible in any way.

Reply on news.ycombinator.com