Ten Things You Can Do with GraalVM (2018) | Hacker News Reader

Ten Things You Can Do with GraalVM (2018)

gist.github.com

51 pointsuticus18 comments

For me the most relevant selling point of GraalVM is beeing able to compile to native self-contained executable. But on the other hand, Golang delivers on this aspect much better (or at least much faster).

This gist narrowly predates Clojure GraalVM tooling that enables eg Babashka and Clojure usage in cloud FaaS with low cold start latency. And quick startup CLI tools like clj-kondo (a Clojure linter).

It seems there's some WebAssembly related things cooking GraalVM, currently just support for running wasm binaries but will be be interesting to see if eventually we get support for targeting WebAssembly (if WebAssembly one day gets good GC support).

The decision to make Clojure JVM based and so slow to startup has slowed it's adoption to a much more significant level than anyone in the Clojure community is willing to accept.

And yet, the percentage of Java programmers using clojure is less than 1%. Looked at another way, how many applications need the fast startup time, and why can’t they be run in a daemon?

I think the lowish % of people using GraalVM, Babashka and ClojureScript-on-Node and lack of other supporting evidence make this theory dubious.

is slow startup really such a big issue for the use cases that clojure aims to address?

I find most web server applications do not require fast startup times. its only recently with the advent of serverless that it is a potential problem.

And for desktop applications, the jvm platform itself is the bigger friction, rather than slow startup times. People just didn't prefer the non-nativeness of the jvm for some reason.

Oh, we know the reason. It is because UI looked ugly and the latency was high.

One thing they didn't mention you can do with GraalVM:

Getting sued by Oracle.

/s noted, and sure Oracle are litigious, but the GPL community version of GraalVM, plus "early adopter" enterprise version licence[0] seems farily clear, and reasonable - at least as far as Oracle are concerned?

[0] https://www.oracle.com/downloads/licenses/graal-free-license... https://blogs.oracle.com/java/post/graalvm-free-license

This is Oracle you are talking about...clear and reasonable are not part of their vocabulary. Fantastic technology, massive legals risks.

"Is GraalVM Free for production use?" - https://lvijay.medium.com/is-graalvm-free-for-production-use...

"...Note that the licensing terms with GraalVM are different from those of OpenJDK. In the case of OpenJDK the risk you open yourself to is security compliance (which you might overcome using other means) in the case of GraalVM you are in violation of the license at the end of 4 years. Unlike security compliance however, you can purchase a license from Oracle and bring yourself into the legal all-clear..."

"Oracle goes on hunt for Java non-compliance" - https://www.computerweekly.com/news/365531580/Oracle-goes-on...

Just stick to the non-enterprise version. Also, a medium article is hardly the arbiter of truth (and it talks about the enterprise version that became free recently)

You nailed it

This was the first thing that came to mind when I saw this.

No sarcasm tag required. Exposure to oracle is a business risk. I expect any architect to think pretty hard before allowing anything owned by oracle into the stack.

RIP Chris, he was a true gem in the community. Often answered questions I had on the Graal slack.

https://news.ycombinator.com/item?id=33893120

Buzz around GraalVM died very quickly though. I had high hopes for it and innovation based on it.

I still have high hopes. But man, the pace of development on this project is slow.

How is it slow? At least compared to similar kind of projects? It is most definitely not a CRUD app you can just throw more devs at.

The project is quite young and already has a JS interpreter that is on-par with V8 when warmed up, and a Ruby interpreter that is roughly 3x faster then the next fastest one. Oh and in the meanwhile, they can run optimizations across language boundaries, that’s just insanely cool!

Sure, the good performance is partially due to the underlying JVM that has seen plenty of development time, but I think that Graal develops in a decent pace.

I was first introduced via TruffleRuby. But since then it's become less clear to me how viable TruffleRuby is versus JRuby.

Reply on news.ycombinator.com