> you would get a simple almost pauseless parallel GC
I don't see why you think you'd do any better than HotSpot's GCs in terms of pauses. You haven't described anything any of the current three production-quality HotSpot GCs don't already do (except for concurrent copying, which Shenandoah does). They also don't use write barriers -- unless you mutate references -- and you'd need those barriers when you mutate in Clojure anyway. I just don't see where the GC you've described differs from Clojure's current GCs.
Also, I'm not sure why you think Clojure data structures contain no loops except when relying on mutable references. Clojure sequences are just an interface, and it's easy to construct a lazy seq that contains loops.
> my point isn't that Clojure on Rust would be faster than Clojure on JVM, it's that Rust code allows much more deterministic performance, better tools for manual optimizations
But Clojure would take away from that deterministic performance and from your ability to manually optimize! Rust is a language designed to achieve good performance -- with safety -- in resource-constrained environments. You then want to take away that advantage by compiling a language that is both too wasteful for such environments and not deterministic.
The JVM has its use-cases and Rust has its own, and Clojure is by far more appropriate for the JVM use-case, so I still don't see the point. For performance sensitive code in Clojure today, you drop down to Java (or Kotlin).
Also, it is extremely hypothetical that you could get a higher-level, less hand-optimized language than Rust to enjoy Rust's benefits (that are bought precisely by paying for them with a more complicated language). I don't see how that could be possible with Clojure. You could, of course, create a more Lispy syntax for Rust -- with Rust semantics and a GC -- but how useful that language would be over, say, Common Lisp is unclear to me.
Think of Rust as a language that makes C++ safer, not as one that makes Java faster/cheaper. Rust can't offer the same abstractions Java/JVM provide for the same low cost -- it offers the same abstractions C++ does, with much better safety. I think that mixing the two will just reduce their advantages.
> which JNI isn't
RustJNI is very nice[1]. Again, I don't see how you think to do better than the current Clojure runtime, which is written in C++. Sure, it might be easier to write in Rust, but the C++ code already exists, and man-centuries of effort have been put into it. Clojure's heavy reliance on interface polymorphism and garbage collection takes advantage of pretty much every optimization provided by that runtime (and more are coming! see later).
> Because of Rust type system you could even isolate threads that have no access to the shared heap and not collect/pause on those - so no chance at pauses at all.
If that's so important, you can do the same with real-time JVMs (RTSJ). They have zero-pause non-heap threads (in fact, they're called NoHeapRealtimeThread[2]), and they access scoped arenas (not that arenas are a good choice for Clojure, a language that tends to produce a lot of garbage even in intermediate computations). A type system is just one way of achieving this isolation, and probably the wrong way to achieve it in Clojure. Plus, Rust's arena's are either type-specific or rely on reflection.
P.S.
IMO, the coolest thing regarding compiling Clojure is now Truffle/Graal -- HotSpot's next-gen JIT and language-compilation platform -- that will be available for stock OpenJDK builds in Java 9. It will allow much more aggressive optimizations for Clojure code. It will also let you write the Clojure machine-code generation logic in Clojure!
I don't see why you think you'd do any better than HotSpot's GCs in terms of pauses. You haven't described anything any of the current three production-quality HotSpot GCs don't already do (except for concurrent copying, which Shenandoah does). They also don't use write barriers -- unless you mutate references -- and you'd need those barriers when you mutate in Clojure anyway. I just don't see where the GC you've described differs from Clojure's current GCs.
Also, I'm not sure why you think Clojure data structures contain no loops except when relying on mutable references. Clojure sequences are just an interface, and it's easy to construct a lazy seq that contains loops.
> my point isn't that Clojure on Rust would be faster than Clojure on JVM, it's that Rust code allows much more deterministic performance, better tools for manual optimizations
But Clojure would take away from that deterministic performance and from your ability to manually optimize! Rust is a language designed to achieve good performance -- with safety -- in resource-constrained environments. You then want to take away that advantage by compiling a language that is both too wasteful for such environments and not deterministic.
The JVM has its use-cases and Rust has its own, and Clojure is by far more appropriate for the JVM use-case, so I still don't see the point. For performance sensitive code in Clojure today, you drop down to Java (or Kotlin).
Also, it is extremely hypothetical that you could get a higher-level, less hand-optimized language than Rust to enjoy Rust's benefits (that are bought precisely by paying for them with a more complicated language). I don't see how that could be possible with Clojure. You could, of course, create a more Lispy syntax for Rust -- with Rust semantics and a GC -- but how useful that language would be over, say, Common Lisp is unclear to me.
Think of Rust as a language that makes C++ safer, not as one that makes Java faster/cheaper. Rust can't offer the same abstractions Java/JVM provide for the same low cost -- it offers the same abstractions C++ does, with much better safety. I think that mixing the two will just reduce their advantages.
> which JNI isn't
RustJNI is very nice[1]. Again, I don't see how you think to do better than the current Clojure runtime, which is written in C++. Sure, it might be easier to write in Rust, but the C++ code already exists, and man-centuries of effort have been put into it. Clojure's heavy reliance on interface polymorphism and garbage collection takes advantage of pretty much every optimization provided by that runtime (and more are coming! see later).
> Because of Rust type system you could even isolate threads that have no access to the shared heap and not collect/pause on those - so no chance at pauses at all.
If that's so important, you can do the same with real-time JVMs (RTSJ). They have zero-pause non-heap threads (in fact, they're called NoHeapRealtimeThread[2]), and they access scoped arenas (not that arenas are a good choice for Clojure, a language that tends to produce a lot of garbage even in intermediate computations). A type system is just one way of achieving this isolation, and probably the wrong way to achieve it in Clojure. Plus, Rust's arena's are either type-specific or rely on reflection.
P.S.
IMO, the coolest thing regarding compiling Clojure is now Truffle/Graal -- HotSpot's next-gen JIT and language-compilation platform -- that will be available for stock OpenJDK builds in Java 9. It will allow much more aggressive optimizations for Clojure code. It will also let you write the Clojure machine-code generation logic in Clojure!
[1]: https://github.com/Monnoroch/RustJni/blob/master/tests/main....
[2]: http://docs.oracle.com/javase/realtime/doc_2.1/release/rtsj-...