On Monday, 28 January 2013 07:56:58 UTC+8, tbc++ wrote:
That's why I think it's a good idea to ask what the goals are for native Clojure. The ClojureScript and Clojure-Py options while nice both don't allow for a good concurrency story. On top of that, I'm not sure either of those would actually run on iOS.Â
However, a pure, from-scratch option has a much smaller ecosystem to draw from. But on the upside, you're also not limited by the host VM. This means that the type system could be based purely on protocols instead of having to fit protocols into a OOP type system.Â
These are the questions I'd like to see people answer here: what hard limits have you hit with Clojure/ClojureScript that you think could be resolved with a native Clojure implementation?
The hard limits I have hit in Clojure are around three specific areas:
1. GC latency on the JVM (usually not a problem, but can be an issue for games and realtime work)
2. Startup latency
3. Access to hardware level features (GPU access, OpenGL etc.)
1. Can be avoided by avoiding memory allocation (there are Java libraries that do this like Javaolution), but this is really hard to do in idiomatic Clojure. Even something as simple traversing a single vector as a sequence is O(n) in new object allocations.
2. Is actually more about the time taken to load / compile the Clojure core libraries than it is about the JVM. On my machine, the JVM itself starts up in about 0.1 sec which is fine for anything other than chaining thousands of script invocations. Generally I think that people who complain about JVM startup time probably have the wrong architecture - you don't spin up a new virtual server to handle every web request, do you?
3. Can be done, but it's a pain to configure
Personally, I think the advantages of being on the JVM vastly outweigh the disadvantages:
- Extremely fast and mature JIT compiler / GC algorithms
- Huge library ecosystemÂ
- Easy portability across platforms
Hence what I'd really like to see are better ways to integrate and / or generate native code within JVM Clojure. In particular:
- Better ways to load / execute native code libraries at runtime
- Macros / tools for accessing natively managed memory while still keeping a Clojure style
- A really good JNA wrapper (clj-native seems along the right track.....)
- A native code compiler that can be executed at runtime. So we can actually compile to native code and run it dynamically. Possibly something based on LLVM would work well here.
If we had all that, we would genuinely have the best of both worlds.
Â