I dunno, it'll certainly revolutionize my world once it's ready. A editor connected REPL, changes to running games on the fly while keeping existing state, using a well-designed language like Clojure but getting the performance (or similar) of C++ and native binaries.
It's pretty much a win-win-win for me, especially if I can replicate the speed of development I get with normal Clojure but for game dev.
Do what? Program games in a Lisp engine? That's quite atypical, which is unfortunate. It's almost impossible to convey the sensation of "living" within a Lisp machine. Those who haven't experienced Lisp programming and haven't become accustomed to the process cannot grasp the dopamine effect of writing instructions virtually anywhere, at any time, changing the things on the fly. It's enormously empowering, and it's incredibly liberating.
That's why those who at least once unleashed the true power of Emacs simply can't feel the same joy in anything else. Other editor and IDEs talk about features like "keyboard macros" and how powerful they are, yet they fail to grasp that Emacs operates on an entirely different plane - its keyboard macros are programmable constructs that can be created, modified at the Lisp expression level, and converted into full-fledged functions from any recorded sequence.
Using Emacs is like playing a video game where you level up by writing s-expressions. The profound satisfaction of shaping the system to match your exact needs is immense, and sadly remains vastly underappreciated. Even when curios newbies come to explore this "immense power of Emacs", they don't even realize that it all is possible only because of Lisp.
It just feels weird to me that the gamedev community outright rejects the idea of programming in Lisp. To me (a Lisper) writing games that way makes absolute sense - games should be written as if you're playing one, right?
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.
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.
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.
This is a weird take. It's a tiny part of game development until you can't program. Then you realize it's actually a huge part. Particularly for "indie" game development.
Ultimately code is just a tool, but it's still a tool that can translate into rapid iteration or into friction.
Yeah, jut like writing is a tiny part of book publishing. What the heck are you even talking about? Programming is absolutely fundamental to game development - it's literally what makes games exist and function.
I'm not talking about "revolutionizing" anything, but maybe you haven't noticed how Unity democratized gamedev and how GDScript made game logic accessible. There is absolutely a sizable chunk of the market for the Lisp-based gamedev - look at Lua/Fennel gaming community - LÖVE2D, Pico-8, Defold engine, etc.
Having performant Clojure option (which Fennel ain't - it's only "like" Clojure) would be absolutely wonderful news.
For indie game devs you're competing against engine ecosystems like Unity, Unreal, Godot. If someone is inclined for more of a DIY route, you're competing against Lua (love2D), C# (monogame), Javascript (...), or for the people who care about performance, C++, Rust, Odin, Zig, and soon even Jai. It's a very crowded competition space and again, I think overwhelmingly the people in this space aren't dreaming of programming in a functional style.
There is also 80% of the mobile phone market available, in the context of JVM like ecosystem to target, and avoiding NDK tooling is gold if one really doesn't need it, as its experience still sucks after all these years.
Many people, especially those coming from FOSS background, don't understand the game development culture is all about IP.
The culture is to create great experiences, with interesting gameplay, the actual programming languages tend to be whatever everyone uses in the industry, and in general proprietary APIs aren't the drama like in sites as this.
So if an indie is going beyond desktop, trying to maximise sales, they will pick an engine and language that covers them.
There's not exactly tiny community (but it's not huge either) that programs against Lua-based engines using Fennel - a Clojure-like Lisp. Jank, aimed to have one-to-one Clojure-parity, I think would be great news.
> the people in this space aren't dreaming of programming in a functional style.
IMO because they are extremely pragmatic and there still, doesn't exist a good, practical way to program games in a functional style. Jank may open that possibility.