Hacker News Reader

Comment by dorfsmay | Hacker News Reader

For me personally I gave up on Clojure because of the JVM. Had there been a Clojure, supported by its main author and community compiling to native, it'd probably be my main language today.

View on HN

Clojurescript is pretty good, too, and can now be self-hosted. So it seems Clojure is not too tightly-bound to JVM.

Early experiments with Graal seems to tell a promising story with regards to compiling to native.

Whenever Graal is mentioned, a host of reservations towards Oracle usually appears though.

Might be, then again no one else bothered to actually save Java, so we get whoever cared, regardless of the monetary reasons.

My concerns about the JVM aren't so much CPU, but memory usage and ease of distribution. Those two factors have, IMO, helped take golang where it is today. Today you cannot run your Clojure apps on a small 250 MB VM, and distributing it means getting the right version of the JVM, the right libraries etc...

I don't know how Graal will handle those two issues, it'll be interesting to watch.

I found this pretty interesting: https://medium.com/criciumadev/serverless-native-java-functi...

Single data point, but nevertheless.

Cold Execution Times:

  Java Function -> 660 ms
  Native Java Function -> 460 ms
  Go Function -> 470 ms

Hot execution times:

  Java Function -> 30 ms
  Native Java Function -> 30 ms
  Go Function -> 30 ms

Container Memory usage of Hot Function:

  Java Function -> 17.8 MiB
  Native Java Function -> 0.9 MiB
  Go Function -> 1.2 MiB

Container Image Size:

  Java Function -> 266 MB
  Native Java Function -> 13.6 MB
  Go Function -> 15.1 MB

What are "Native Java Functions"?

Already compiled to bytecode?

Machine code.

Where is Go?

Still not a match for Hotspot and around me everyone still asks for .NET and Java projects.

And those data structures with indirect calls are never going to go away.

Reply on news.ycombinator.com