3 ms·

In my mind, 1½ seconds is huge; that essentially rules out any interactive usage. It's even annoying for rapid development cycles. Only low expectations or heav

• kasey_junk 10y ago
  It rules out any interactive usage where you are starting and stopping the jvm, like in a command line context. There are work arounds for this (things that reuse jvms and such) but until that is overcome the jvm is largely not appropriate for cli tools that start/stop. But for other kinds of interactive programs, things with long running sessions and such, it is pretty easy to a) lower that startup time and b) do things that mitigate it to the user.
  • derefr 10y ago
    I've always thought it'd be nice to build a sort of hybrid between a "ClojureScript for bash", and a Java boot-script + RPC client. Picture a Clojure macro library just for writing CLI driver programs, where you could call all your Clojure code like normal, and where some of the subcommand-defining methods of the driver program could be annotated with something like "@inline". The un-annotated subcommands, as a simpler case, would translate into calls to spawn a JRE and feed your ARGV over to it once it gets running. These would be the slow-startup calls, so you'd just use them for the things that need the full "horsepower" of the JVM. The @inline subcommands, on the other hand, would grab your app, its deps, and the JRE, do a whole-program dead-code-elimination process over them to trim them down to just what that subcommand needs, and then would transpile that whole resulting blob to bash code and shove it into a bash function. (So, something like Emscripten with a different frontend + backend.)
• jeremiep 10y ago
  That's completely false in the context of a Lisp. I boot the JVM once and iterate endlessly in the same process. Same for ClojureScript in the browser or node.js. Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK). 1.5 seconds would be huge if you had to constantly restart your application like you do everywhere outside Lisp. Iterating in Clojure is literally instant. I wrote applications in dozens of languages, and none come remotely close to Clojure's iteration speed or joy of use.
  • bandrami 10y ago
    Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK). That's Forth. Lisp comes next.
  • icebraining 10y ago
    if you had to constantly restart your application like you do everywhere outside Lisp. This was probably true in the 80s, but hasn't been in a while. Many languages have this, either built-in or as a tool. In the case of the JVM, there's spring-loaded, which works in Java, Groovy, etc.
• maaaats 10y ago
  That 1.5 seconds is FUD anyway.
• eveningcoffee 10y ago
  1.5 is huge, except it is completely wrong. JVM startup time is within fraction of the second.
  • akvadrako 10y ago
    You are right, I was just going with what the grandparent said. But I think with normal amounts of class scanning and other overhead, 1.5 seconds becomes the practical normal. Certainly the JVM startup always feels slow, in my experience.
    • eveningcoffee 10y ago
      Well, if you create a lot of additional objects on startup then it will take some time. JVM startup is still fast. http://blog.ndk.io/jvm-slow-startup.html http://blog.ndk.io/jvm-slow-startup.html
      • akvadrako 10y ago
        That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.
        • mickronome 10y ago
          1.2 seconds was hello world in clojure, the Java hello world presented the numbers below, so it's mostly clojure that is slow: $ time java Hello Hello world 0.04user 0.01system 0:00.12elapsed 43%CPU (0avgtext+0avgdata 15436maxresident)k 29672inputs+64outputs (82major+3920minor While 120ms elapsed is not stellar, it's rarely a problem with how the JVM ecosystem looks.
        • dkersten 10y ago
          That's clojure, not java. JVM startup is much faster.
        • eveningcoffee 10y ago
          Please be kind to reread it. Startup time of a simple Java application and therefore also whole JVM is 0.4s (in the linked article). 1.2s is for the implementation in Closure that includes its additional quite heavy runtime.