Live data from Hacker News

GraalVM: Run Programs Faster Anywhere

graalvm.org

111–120 of 218 posts

Re: GraalVM: Run Programs Faster Anywhere

#111
post #18

Earlier quoted context omitted.

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.

> if I built an application with truffleruby, could I distribute it as a JAR Yes there is a Java embedding API. http://www.graalvm.org/docs/graalvm-as-a-platform/embed/ > (provided that it was run under JDK 9) It can run on 8. It'll be fast on JDK 9 or 10 because these have the interface to use Graal. > Are there ways to call out to Java like JRuby? JRuby compatible interop: https://github.com/oracle/truffleruby/blob…

Actually, can you create a Graal/Truffleruby 101 example where a Ruby application is compiled to native and run ?

Re: GraalVM: Run Programs Faster Anywhere

#112

Keep in mind that while this is nice technology, it's Oracle-based, split in CE/EE (which in itself is not a problem, but CE doesn't run on macOS), and they will find a way to screw you over at some point in the future regardless of what you do, use or choose.

I am curious how GPL2 will intersect with "You can't reimplement our API in your own project."

Re: GraalVM: Run Programs Faster Anywhere

#113

Earlier quoted context omitted.

> if I built an application with truffleruby, could I distribute it as a JAR Yes there is a Java embedding API. http://www.graalvm.org/docs/graalvm-as-a-platform/embed/ > (provided that it was run under JDK 9) It can run on 8. It'll be fast on JDK 9 or 10 because these have the interface to use Graal. > Are there ways to call out to Java like JRuby? JRuby compatible interop: https://github.com/oracle/truffleruby/blob…

Actually, can you create a Graal/Truffleruby 101 example where a Ruby application is compiled to native and run ?

It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application.

It's a little bit more complex than that in that we can run a Ruby application ahead of time up to a certain point where we compile it, and then when you run the application that state when it was compiled is restored. So we load the core library during compilation for example.

Re: GraalVM: Run Programs Faster Anywhere

#114

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…

> GraalVM is available as Community Edition (CE) and Enterprise Edition (EE). The current release is based on JDK 8. Why is this ? We are currently on JDK 10. Also - why is there no official Graal Python ?

I think Java 8 is the current LTS release isn’t it? Graal needs a stable platform to build on.

And there is an official Python alongside the other languages.

Re: GraalVM: Run Programs Faster Anywhere

#115

Earlier quoted context omitted.

This was the first thought that crossed my mind. If I have a choice between running our stack 50 times slower (and thereby 50 times the cost) or running anything Oracle, I know which choice is cheaper and doesn't come with an existential threat to my company. Only governments and big corp are rich and reckless enough to take on this kind of risk willingly.

>> existential threat to my company There is like a bajillion people out there running Oracle Java, MySql, Virtualbox and so on. All of them Oracle products, and with permissive licenses. Where is this "existential treat" thing coming from?

>There is like a bajillion people out there running Oracle Java, MySql, Virtualbox and so on. All of them Oracle products, and with permissive licenses. Where is this "existential treat" thing coming from?

Oracle. (see, I can be sarcastic too)

Ignoring the fact that most of those users were likely acquired back when those products were still known as Sun Java, Sun MySql, and Sun Virtualbox, those "bajillion" people are not lucrative enough to warrant the effort. The moment one of those people becomes large enough, Oracle's lawyers will come knocking. If you're large enough, they will even go as far as to change how copyright law itself is interpreted to get their fill.

With a company like that, entering any form of contract or agreement is a major liability and an existential threat.

Re: GraalVM: Run Programs Faster Anywhere

#116
post #77

Keep in mind that while this is nice technology, it's Oracle-based, split in CE/EE (which in itself is not a problem, but CE doesn't run on macOS), and they will find a way to screw you over at some point in the future regardless of what you do, use or choose.

Oh come on, I'm no fan of Oracle but this is some FUD nonesense..

Oracle has an extensive history of screwing developers and companies with IP laws, being suspicious of projects coming from Oracle is only a valid reaction on the history of the company.

Re: GraalVM: Run Programs Faster Anywhere

#117
Is there public documentation for the differences between the CE and EE editions? The website mentions that EE "provides improved performance and security for production deployments". What types of performance and security optimizations are locked behind the EE edition? What is your criteria for determining whether a new optimization belongs in CE or EE?

I also want to echo others' concerns about the license, lock-in, and lack of explicit patent grant. It's a shame that Oracle's (well-deserved) reputation is tainting so many excellent engineering efforts. I hope that these comments serve as some form of feedback about the very real cost the Oracle brand has suffered as a result of its legal activities.

Re: GraalVM: Run Programs Faster Anywhere

#118

I wonder what this means for Clojure and Clojurescript developers

For Clojure, I think it means native compilation, with fast startup times, and the ability to interop with Python, Ruby, or any of the other Graal languages. Not sure there would be an advantage to re-implementing a Clojure on Graal. Clojure is not an interpreted language like Ruby, JavaScript and Python is, so I don't think Graal adds as much benefit here.

For ClojureScript, it would mean full circle. You could run your ClojureScript back on the JVM, and have Java interop from it.

Re: GraalVM: Run Programs Faster Anywhere

#119

Keep in mind that while this is nice technology, it's Oracle-based, split in CE/EE (which in itself is not a problem, but CE doesn't run on macOS), and they will find a way to screw you over at some point in the future regardless of what you do, use or choose.

I am curious how GPL2 will intersect with "You can't reimplement our API in your own project."

[deleted]

Re: GraalVM: Run Programs Faster Anywhere

#120

Earlier quoted context omitted.

Actually, can you create a Graal/Truffleruby 101 example where a Ruby application is compiled to native and run ?

It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application. It's a little bit more complex than that in that we can run a Ruby application ahead of time up to a certain point where we compile it, and then when you run the application that state when it was compiled is restored. So we load the core library during compilation for example.

Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program?

Will this be the case for truffle python, js,etc ?

Post reply on HN