Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraalVM: Run Programs Faster Anywhere

graalvm.org

Post reply on HN
Print view View original

11–20 of 218 posts

Re: GraalVM: Run Programs Faster Anywhere

#11

Post by aardvark179 »

holydude wrote: post #3

This is seriously huge. I wonder if it actually gets popular. Can anyone comment on TruffleRuby ? What remains to be done for it to be production ready ? GraalVM page still mentions it's experimental.

We are getting there, lots of things work right out of the box just fine. C extensions are still being actively worked on as they often need some amount of patching because of assumptions they make about types and so forth. I think we can reduce that, but I doubt it can will disappear entirely, but in the end I hope extension authors will test on TruffleRuby themselves and patch the code themselves.

Re: GraalVM: Run Programs Faster Anywhere

#12

Post by aardvark179 »

mc13 wrote: post #5

Great! Benchmarks of TruffleRuby vs JRuby vs Ruby looks very promising. edit: https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...

If we can successfully JIT it we normally do very well. The caveat is that we do have warm up time and if we can’t compile stuff then you won’t see the same level of performance.

Re: GraalVM: Run Programs Faster Anywhere

#13

Post by joeschmoe3 »

Steltek wrote: post #7

Am I correct in reading the license in Github that this is all GPL? Albeit GPL2 but still not some Oracle proprietary license. "One VM to rule them all" reminds me of Parrot VM (for Perl 6). Looks like development slowed down a year or two ago. Back then, it got me excited as it looked like the "open source community" alternative to "Big Corporate Java". https://en.wikipedia.org/wiki/Parrot_virtual_machine

What is the license of GraalVM?

There is a community edition (CE) and an enterprise edition (EE) of GraalVM. The community edition is distributed under an open source license. It is free to use in production and comes with no strings attached, but also no guarantees or support. The enterprise edition is available from the Oracle Technology Network under an evaluation license. It provides improved performance and security for production deployments. If you are interested in using the enterprise edition in production, please contact graalvm-enterprise_grp_ww@oracle.com.

Re: GraalVM: Run Programs Faster Anywhere

#14

Post by seiferteric »

Steltek wrote: post #7

Am I correct in reading the license in Github that this is all GPL? Albeit GPL2 but still not some Oracle proprietary license. "One VM to rule them all" reminds me of Parrot VM (for Perl 6). Looks like development slowed down a year or two ago. Back then, it got me excited as it looked like the "open source community" alternative to "Big Corporate Java". https://en.wikipedia.org/wiki/Parrot_virtual_machine

I was very interested in Parrot VM for a while too for the same reasons. I always liked the idea of language interoperability and being able to use the best libraries of each language. This brings me to a question I have had for a while, why do we even have so many language specific libraries for common tasks instead of more "universal" libraries with bindings for each. Of course these exist, but I feel like this should be almost the default, and language libraries would just be wrappers to help it integrate better with the language (like making it more pythonic for python etc). That way you would have at most a few competing libraries for each task with higher quality. Also it would be easier to bootstrap new programming languages since that is a big initial barrier (having few libraries).

Re: GraalVM: Run Programs Faster Anywhere

#15

Post by claytongulick »

This project is remarkable! Really excited to see where it goes. The biggest problem I see so far is sparse docs on interop. I see docs with a trivial example of importing simple types from java and using them in node, which is amazing! However, this is pretty far from a real world example. In the real world there are deep type graphs and dependencies and functions that look like IWidgetInterface createWidget(IAbstractWidgetFactory factory) etc... seeing examples of dealing with complex types, anonymous Callables, generics, etc... would be great.

Re: GraalVM: Run Programs Faster Anywhere

#16

Post by grashalm »

Graal dev here. If you want to checkout all the sources/licenses of GraalVM CE. They are here:

Graal: https://github.com/oracle/graal (GPLv2 with CPE)

JavaScript with Node Integration: https://github.com/graalvm/graaljs (UPL - BSD license)

Ruby: https://github.com/oracle/truffleruby (EPL, GPLv2, LGPL)

R: https://github.com/oracle/fastr (GPLv2)

Python: https://github.com/graalvm/graalpython (UPL - BSD license)

LLVM/Sulong: https://github.com/graalvm/sulong

Re: GraalVM: Run Programs Faster Anywhere

#17

Post by RussianCow »

seiferteric wrote: post #14
Steltek wrote: post #7

Am I correct in reading the license in Github that this is all GPL? Albeit GPL2 but still not some Oracle proprietary license. "One VM to rule them all" reminds me of Parrot VM (for Perl 6). Looks like development slowed down a year or two ago. Back then, it got me excited as it looked like the "open source community" alternative to "Big Corporate Java". https://en.wikipedia.org/wiki/Parrot_virtual_machine

I was very interested in Parrot VM for a while too for the same reasons. I always liked the idea of language interoperability and being able to use the best libraries of each language. This brings me to a question I have had for a while, why do we even have so many language specific libraries for common tasks instead of more "universal" libraries with bindings for each. Of course these exist, but I feel like this sho…

This is exactly the case with JVM languages today: Every language has its own idiomatic abstractions, but everything is ultimately based on the underlying Java libraries.

Re: GraalVM: Run Programs Faster Anywhere

#18

Post by leoh »

grashalm wrote: post #16

Graal dev here. If you want to checkout all the sources/licenses of GraalVM CE. They are here: Graal: https://github.com/oracle/graal (GPLv2 with CPE) JavaScript with Node Integration: https://github.com/graalvm/graaljs (UPL - BSD license) Ruby: https://github.com/oracle/truffleruby (EPL, GPLv2, LGPL) R: https://github.com/oracle/fastr (GPLv2) Python: https://github.com/graalvm/graalpython (UPL - BSD license) LLVM/Su…

Thanks! Out of curiosity — if I built an application with truffleruby, could I distribute it as a JAR (provided that it was run under JDK 9)? Are there ways to call out to Java like JRuby? Having some difficulty finding documentation around this.

Re: GraalVM: Run Programs Faster Anywhere

#19

Post by dragonwriter »

seiferteric wrote: post #14
Steltek wrote: post #7

Am I correct in reading the license in Github that this is all GPL? Albeit GPL2 but still not some Oracle proprietary license. "One VM to rule them all" reminds me of Parrot VM (for Perl 6). Looks like development slowed down a year or two ago. Back then, it got me excited as it looked like the "open source community" alternative to "Big Corporate Java". https://en.wikipedia.org/wiki/Parrot_virtual_machine

I was very interested in Parrot VM for a while too for the same reasons. I always liked the idea of language interoperability and being able to use the best libraries of each language. This brings me to a question I have had for a while, why do we even have so many language specific libraries for common tasks instead of more "universal" libraries with bindings for each. Of course these exist, but I feel like this sho…

> This brings me to a question I have had for a while, why do we even have so many language specific libraries for common tasks instead of more "universal" libraries with bindings for each.

A lot of language specific libraries incorporate foreign language (often C) libraries and add additional functionality thst fits the ergonomics of the target language, rather than being a thin wrapper around a language neutral library. This is more than aesthetic when the target language has, for example, differences in type system or fundamental guarantees from the underlying library's language.

OTOH, sometimes there aren't C (etc.) libraries, and it's more straightforward to implement a library in (say) Python. But once you have a Python library, calling into it from Rust, C, Erlang, or even a broadly similar language like Ruby is, to put it mildly, non-trivial.

Re: GraalVM: Run Programs Faster Anywhere

#20

Post by jerf »

seiferteric wrote: post #14
Steltek wrote: post #7

Am I correct in reading the license in Github that this is all GPL? Albeit GPL2 but still not some Oracle proprietary license. "One VM to rule them all" reminds me of Parrot VM (for Perl 6). Looks like development slowed down a year or two ago. Back then, it got me excited as it looked like the "open source community" alternative to "Big Corporate Java". https://en.wikipedia.org/wiki/Parrot_virtual_machine

I was very interested in Parrot VM for a while too for the same reasons. I always liked the idea of language interoperability and being able to use the best libraries of each language. This brings me to a question I have had for a while, why do we even have so many language specific libraries for common tasks instead of more "universal" libraries with bindings for each. Of course these exist, but I feel like this sho…

There are fundamental semantic differences between the languages. An immutable language will always have a serious impedance mismatch with a mutable library. A library that uses GC won't work in a language without them, a specific example of the general principle that memory management strategies vary widely. A library that uses dynamic types will have a huge conversion boundary with a statically-typed language, and vice versa. A library that uses threads, or expects threads, will have a hard time working in an event-based environment that depends on code voluntarily yielding to maintain its responsiveness. A language that wants to provide guarantees about correctness or whathaveyou is forced to give all those up to talk to a lowest-common-denominator library.

And that's just the top-level differences. It gets worse as you get into the details of API style and the costs of the indirection layers to convert into the local style, assuming conversion is even technically possible.

Even if you write with the lowest possible common denominator of C or Rust with no runtime, you'll still encounter a significant subset of those issues. And of course we still will use such things; all serious languages can communicate in some manner with a C implementation of a library. (Not for any theoretical reasons, really, C has more opinions than people often realize, but because it's still the baseline current systems are built on.) But it can't be as good as a native implementation.

Post reply on HN