Hacker News new | ask | show | jobs
by threeseed 4115 days ago
This seems like bit of a short sighted move not that I disagree with it.

Project Jigsaw which will be a big part of Java 9 aims to make the JVM more modular which will reduce the memory footprint substantially. Personally I would like to see a version of Clojure that targets this JVM specifically and abandons backwards compatibility.

Leaving the JVM means you abandon the decade of libraries many of which you simply can't get on any other platform (in particular for the enterprise). Given that Clojure has been gainingĀ a lot of ground in these large companies it seems like a missed opportunity.

5 comments

In fact JVM is pretty fast. If you run a simple java app without dependencies and only displaying "Hello world" it will run in about 1s on modern hardware. The problem with Clojure is AFAIR related to parsing and loading a big number of namespaces which is quite slow.
1s to print hello world is an awful lot I would like to point out.
Upvoted you because I agree. JVM has many strong points but I don't think anyone is disputing that startup time is a weakness. I've used some java tools that you invoke from a command line and I'm always slightly annoyed by how slow they are.

As an aside - I was trying to reduce -Xmx to improve HelloWorld startup (lol idk...) and Xmx smaller then 1024k and it couldn't start up with less then 1024k so there's that.

On my windows computer (also I barely know what I'm doing so probably even timing it wrong).

  [Mon Mar 09 03:22:31 zebra@ZEBRA:~ ]
  $ time a.exe
  Hello, world
  real    0m0.098s
  user    0m0.015s
  sys     0m0.015s
  [Mon Mar 09 03:22:34 zebra@ZEBRA:~ ]
  $ time java Hello
  Hello, world!

  real    0m0.285s
  user    0m0.000s
  sys     0m0.031s
Worry about -Xms rather than -Xmx for startup times.

I suspect there are ways to make it faster (e.g. there's a nashorn runner that starts up appreciably faster than "proper" java), but the main use case for java is server-side programs that run for days or weeks between restarts, so it's optimized for that use case.

the main use case for java is server-side programs that run for days or weeks between restarts, so it's optimized for that use case.

Unfortunately for the folks who still have to use Java desktop software written in Swing.

Sure it's a lot, but clojure startup times are significantly longer than that.
> If you run a simple java app without dependencies and only displaying "Hello world" it will run in about 1s on modern hardware.

> time for x in $(seq 1 100); do ./helloworld.py ; done

    real    0m1.240s
    user    0m0.902s
    sys     0m0.343s
That's reasonably fast.

Java for comparison:

> time for x in $(seq 1 100); do java Hw; done

    real    0m4.952s
    user    0m4.051s
    sys     0m1.071s
And I had to compile java first. Still, I expected worse from java TBH.
Out of curiosity which Java? OpenJDK or Oracle or IBM?

     > java -version
     java version "1.7.0_72"
     Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
     Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
Thanks. I would have figured hot spot to be better.
You mean 60-80ms. Not 1s. Try it.
It can call into C libraries so there is a whole other ecosystem available to it.
Which is nice. And it could definitely open up new avenues for them.

But for example one of the areas that Clojure has been doing well in is the enterprise big data space which is dominated by the JVM based Hadoop ecosystem. Likewise many companies feel comfortable bringing in Clojure because they can leverage their existing Java libraries.

My point was that getting rid of the JVM loses a lot of what made Clojure actually successful.

Who got rid of the JVM? Pixie is not Clojure 2. Clojure still exists and you can use it, but now Pixie also exists and you can also use it. There is no downside unless you think developing languages which don't run on the JVM is a waste of time.
Yes, but Clojure can call the same C libraries, plus the JVM ones.
From the README

> Although parts of the language may be very close to Clojure (they are both lisps after all), language parity is not a design goal. We will take the features from Clojure or other languages that are suitable to our needs, and feel free to reject those that aren't. Therefore this should not be considered a "Clojure Dialect", but instead a "Clojure inspired lisp".

And I agree that seeing maybe Clojure 2.0 abandon backwards compatibility with Java < 9 would be nice.

> This seems like bit of a short sighted move ... Leaving the JVM means you abandon the decade of libraries

Pixie is not officially connected to Clojure in any way.

The creator has been involved in Clojure's development, and is remixing parts he likes into a new language and platform. I would peg this more as a research project that the Clojure team could take some pointers from.

Jigsaw keeps getting moved back, to the point that I don't have much faith it will be in version 9. Wait and see, I guess.