News for hackers. Stuff that matters.

A comment on The Machine That Builds Itself: The Strengths of the Lisp Languages (2016). Parent comment

Re:The Machine That Builds Itself: The Strengths of the Lisp... by dorfsmay on Monday July 02, 2018 @09:29AM (#17441436)
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.
[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by vt100 on Monday July 02, 2018 @11:38AM (#17442573)
Clojurescript is pretty good, too, and can now be self-hosted. So it seems Clojure is not too tightly-bound to JVM.
[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by fnordsensei on Monday July 02, 2018 @09:45AM (#17441535)
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.

[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by pjmlp on Monday July 02, 2018 @11:29AM (#17442482)
Might be, then again no one else bothered to actually save Java, so we get whoever cared, regardless of the monetary reasons.
[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by dorfsmay on Monday July 02, 2018 @10:03AM (#17441688)
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.

[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by fnordsensei on Monday July 02, 2018 @11:36AM (#17442555)
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
[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by dorfsmay on Monday July 02, 2018 @02:25PM (#17444184)
What are "Native Java Functions"?
[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by tkxxx7 on Monday July 02, 2018 @02:48PM (#17444364)
Already compiled to bytecode?
[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by pjmlp on Tuesday July 03, 2018 @07:59AM (#17449423)
Machine code.
[ Parent | on HN ]
Re:The Machine That Builds Itself: The Strengths of the Lisp... by pjmlp on Monday July 02, 2018 @11:32AM (#17442512)
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.

[ Parent | on HN ]