Fork me on GitHub
#graalvm
<
2021-01-19
>
littleli18:01:46

improved method handles support for native-image hyper-clap

borkdude18:01:38

I am watching their live stream (link above)

lukasz18:01:51

cue in the "yo dog" Xzibit joke

borkdude18:01:45

What this means: they implemented a Truffle interpreter for Java.

borkdude18:01:58

This means you can now compile and run Java from source from within a native-image

borkdude18:01:13

(not performantly yet, but they focused on compatibility first)

lread19:01:25

Truffle can run bytecode too, I’ve never tried truffle. Does it have fast start up time?

borkdude19:01:16

> Truffle can run bytecode too This is the new part, announced today.

borkdude19:01:48

Truffle is a framework for creating interpreters that are self-optimizing. Languages implemented in Truffle can interop with each other.

borkdude19:01:01

So you can have Ruby <-> Python interop if you use both Truffle implementations

borkdude19:01:11

and a Truffle interpreter can be used inside a native-image

borkdude19:01:34

So theoretically we can have the official JVM Clojure compiler, interpreted by Truffle Java, which runs inside a native-image.

lread20:01:39

Very interesting!

mkvlr20:01:43

@borkdude great stuff, did you play with it already?

borkdude20:01:18

sorry, I'm quite lazy, not yet ;)

borkdude20:01:15

I wonder if we can run the Clojure compiler from bytecode using Truffle Java in a native-image .. and what consequences this would have

zane02:01:32

> Mixing AOT and JIT is a fascinating option for applications that cannot leverage the native image performance improvements because their functionality depends on dynamic code which does not work easily with Native Image. > This bit sounded promising?

mkvlr20:01:44

yeah, same

mkvlr20:01:14

does that make Clojure a truffle language now that Java is one?

borkdude20:01:57

There is a thesis about a Clojure Truffle implementation from 2015 btw, but I don't think the source is public

mkvlr20:01:18

it’s also pretty dated, I hear truffle came a long way since then

borkdude20:01:29

I think having a proper Clojure on Truffle implementation would be faster than running the Clojure compiler through Java on Truffle, but I guess people should start experimenting with this

mkvlr20:01:02

I want to play with this, but only after I’ve completed SICP, currently halfway in chapter 3

borkdude20:01:22

Someone told me that sci is a meta-circular interpreter like written in SICP. I have SICP but I never really read it. Then I started in chapter 5 and omg, yes, this is more or less what it is ;)

mkvlr21:01:26

two more sections in chapter 3 until I’m finally there…

mkvlr20:01:40

@eggsyntax did you ever get in touch with Thomas? I saw your tweet https://twitter.com/eggsyntax/status/992523127988121600

eggsyntax20:01:13

I emailed him but never heard back. I'll PM you his email in case you want to give it a try (and if you do get it I'd be curious to take a look).

👍 3
eggsyntax20:01:13

I emailed him but never heard back. I'll PM you his email in case you want to give it a try (and if you do get it I'd be curious to take a look).

👍 3
eggsyntax20:01:38

Unfortunately it looks like the link to the actual masters' thesis now goes to a one-page summary. I may still have a copy around if anyone wants to read it.

littleli21:01:03

I don't believe much there would be significant benefit to rewrite Clojure as Truffle language. Maybe like 20-25% max at peak. Clojure compiler produces already quite effective code. I don't have numbers, but as a former Oracle Labs employee I had some very interesting discussion with Graal/Truffle people in the kitchen :-)

littleli21:01:23

Of course Clojure compiled to Java bytecode can already benefit from improved escape analysis and other goodies offered by GraalVM bytecode interpreter.

borkdude21:01:27

@ales.najmann The fun thing about Truffle languages is that they can also be compiled along in a native-image.

borkdude21:01:50

or I should say, one fun thing

littleli21:01:57

Yes and they are more natural fit of course

borkdude21:01:13

another fun thing is polyglot: one could reach Clojure programs from other languages like Python (not that I'm personally interested in this)

mkvlr21:01:21

@borkdude but isn’t that also true for Clojure in Java now?

mkvlr21:01:41

compiling along I mean

borkdude21:01:45

well, I mean, eval would then "just work" and that doesn't right now

phronmophobic21:01:13

it will be interesting if any of these avenues opens up an opportunity for clojure to run well on mobile. I now cljs can be used for mobile apps, but I think a compiled or sufficiently efficient intrepreter would be really cool.

borkdude21:01:10

In that area, this could also be interesting: https://twitter.com/cgrand/status/1350063059864346624

borkdude21:01:15

I have never tried to do mobile with graalvm, or really anything, but I've heard people make apps with it and deploy them to the app store. I think you could do this without truffle though and just write Clojure bindings for the appropriate framework e.g. JavaFX

borkdude21:01:28

which already exist

phronmophobic21:01:00

lots of exciting stuff. it's potentially already possible, but I haven't had a chance to try the options

phronmophobic21:01:53

I have my own platform agnostic UI library that is graalvm compatible. at some point I'd like to try and compile and link it to iOS/android skia libs for making mobile apps with clojure, but I'm not sure what all the obstacles might be

borkdude21:01:48

@U7RJTCH6J Ah, that's the one which also supports lanterna right?

borkdude21:01:21

We have tried upgrading lanterna to 3.0 for the clojure-lanterna lib here: https://github.com/babashka/clojure-lanterna

phronmophobic21:01:27

yep, and skia, skija, javafx, swing, and webgl!

phronmophobic21:01:49

ideally, it would be great to be able to mix and match (re-frame, fulcro, reagent, etc) with platform (terminal, desktop, web, and mobile, etc)

zane02:01:32

> Mixing AOT and JIT is a fascinating option for applications that cannot leverage the native image performance improvements because their functionality depends on dynamic code which does not work easily with Native Image. > This bit sounded promising?