"Reference counting is the current design. This is something I'll be digging more into, but I really don't think a GC would be ideal."
Internally this is done with structural sharing, so it's way faster than copy on write, but it's still potentially allocating a half dozen objects for what would usually be a trivial operation that does not involve allocation.
On the plus side, Clojure in theory has some pretty nice guarantees that older objects can't point to newer objects. From memory Haskell takes advantage of these guarantees to accelerate its version of eden. There may be a way to get a fast GC that's not nearly as complex as the full JVM GC.
> The only reason Clojure is viable for production use is because it relies on the really good JVM GCs. How will Jank try to solve the the GC problem?
I think this original statement is wrong because people are fine with poor performance (see Python, Ruby) if the language (ecosystem) is effective. And Clojure is effective (IMO) moreso because of the JVM ecosystem not the JVM's performance.