Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'll try to dispel some of the concerns about Clojure.

1) Stacktraces in JVM may be ugly, but the amount of insight into runtime issues that the JVM offers you is generally way higher than in runtimes like cpython or MRI.

2) Clojure gives you a rather elegant way to work with the different JVM number types as it offers literals for those. I think Java Longs (the integer default) should be long enough as it's a 64 bit value. And on the floating point side the default is a double, which also seems nice to me. See: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/dat...

Above this Clojure offers BigDecimal literals and native ratios.

3) The startup time is gigantic. However, while developing you usually should not have to restart the JVM as you can update the JVM with new bytecode through the REPL. This should also dispel the concern about unit tests (although I'm not sure you can reach the necessary speed, if you talk about < 0.5 second unit tests, because the code needs to be compiled to JVM bytecode 1st. There's definitely still potential there.



One thing I've noticed is that the JVM startup time is actually pretty small. What's slow is waiting for Clojure to bootstrap itself.


Detailed discussion on startup times at http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-start... (and subsequent articles by the same author).


JVM Feature Request: The ability to preserve a complete JVM state (in this case with loaded Clojure stuff) and quickly start from there.

Does anybody know if something like that is possible/already exists?



I have used http://criu.org/ on Ubuntu 14.04 to checkpoint and restore a Java process running a Clojure nREPL server. It took 480 ms to checkpoint a 128MB process and 213 ms to restore on a 2.4ghz E5645.


Not quite what you asked, but I found people recommending this.

https://github.com/ninjudd/drip


> Does anybody know if something like that is possible/already exists?

The majority of commercial JVMs that tend to be ignored on HN, provide JIT cache between runs and AOT compilation.


That's true, but it's generally like this with any Java application. The JVM starts in 0.3 seconds, but loading all your classes usually takes seconds. I don't know the arcitecture well enough, but I think it's because it looks for classes in a lot of places and unpacks JAR files etc.


That of course depends on the number of deps that you have, but you have to have a _lot_ to reach into the second range.


Yep. A JVM doesn't take more than a about 100ms to start up. But Clojure takes a long time, and Leiningen is slow as hell.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: