GraalVM

GraalVM, a language backend that languages can compile to so they run on the JVM (as an example, it even supports LLVM Assembly so it can run some C/C++ programs on the JVM) just hit 1.0!

https://www.graalvm.org/

7 Likes

For example TruffleRuby is based on it.

1 Like

This is one of those rare times when the company that makes/releases/has the license to something actually makes me completely uninterested in the thing. GraalVM could be the second coming of Christ but Iā€™d still stay away from anything Oracle makes.

9 Likes

Implementing your own language using GraalVM will not only give you high performance. More importantly, it allows your language to connect with the rich tooling provided by the GraalVM ecosystem. Also, it enables your language to run in the context of any GraalVM embedding.

I wan some ML language :slight_smile:

Oracle Owns ā€œJavascriptā€, so Apple is taking down my app
https://twitter.com/benschwarz/status/986712202991169537
Understanding Oracle Java SE Licensing

3 Likes

Seems that .Net Core has better license than JVM :slight_smile:

.NET Core repos typically use either the MIT or Apache 2 licenses for code. Some projects license documentation and other forms of content under Creative Commons Attribution 4.0.

Graal license
Not quite sure what is class path exception
OK I see

ā€œCLASSPATHā€ EXCEPTION TO THE GPL

Certain source files distributed by Oracle America and/or its affiliates are subject to the following clarification and special exception to the GPL, but only where Oracle has expressly included in the particular source fileā€™s header the words ā€œOracle designates this particular file as subject to the ā€œClasspathā€ exception as provided by Oracle in the LICENSE file that accompanied this code.ā€

Linking this library statically or dynamically with other modules is making
a combined work based on this library. Thus, the terms and conditions of
the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent modules,
and to copy and distribute the resulting executable under terms of your
choice, provided that you also meet, for each linked independent module,
the terms and conditions of the license of that module. An independent
module is a module which is not derived from or based on this library. If
you modify this library, you may extend this exception to your version of
the library, but you are not obligated to do so. If you do not wish to do
so, delete this exception statement from your version.

License
Truffle and its dependency Graal SDK are licensed under the GPL 2 with Classpath exception.

The Tools project is licensed under the GPL 2 with Classpath exception.

The TRegex project is licensed under the GPL 2 with Classpath exception.

The Graal compiler is licensed under the GPL 2.

The Substrate VM is licensed under the GPL 2.

2 Likes

Seems promising but not actually attractive for me. Since itā€™s just yet another virtual machine, it does not change the way we write code.
BEAM is a little bit different because itā€™s more like an operating system rather than a traditional language runtime. Remember some ideal designs in lisp machine?

But seriously just be careful when using product from Oracle or Microsoft.

1 Like

Heh, yeah thatā€™s why Iā€™ve had it on my watch lists for years at this point (hence why I got the 1.0 notification), but never bothered to actually touchā€¦ >.>

Itā€™s not ā€œanother virtual machineā€, it is a layer that makes it easy to target, that in turn targets the JVM.

+1

GraalVM is highly interesting. I know yeah Oracle - big parts of it are open source though. Sadly I heard that some of the more interesting parts are going into the closed source portions though.

The open source ruby implementation managed to achieve phenomenal performance and even managed to improve upon that - I didnā€™t run benchmarks again this year (yet) but last yearā€™s were very promising: https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-ai-in-ruby-cruby-vs-rubinius-vs-jruby-vs-truffle-a-year-later/

This all comes with the caveat that the warmup times are HUGE - and Iā€™m talking huge by JVM standards. The simple benchmark linked above needed over a minute of warmup. On even smaller benchmarks middle of last year the warmup was still so big that how you measure with startup and warmup involved completely turns the outcome of the benchmark on its head: https://pragtob.wordpress.com/2017/08/29/careful-what-you-measure-2-1-times-slower-to-4-2-times-faster-mjit-versus-truffle-ruby/

The other caveat is that to the best of my knowledge truffleruby still doesnā€™t fully run rails although I might have missed the news (it seems that this was their goal for the past 2 years).

Nevertheless, an incredibly talented team is working on it and itā€™s some seriously interesting research and possibility to create languages. I know JVM and co get a lot of hate, but imo theyā€™ve established themselves as a pretty good language platform.

No, i"m not hating on the BEAM - I love the BEAM. But that doesnā€™t mean that there canā€™t be multiple good VMs out there :slight_smile:

1 Like

Yeah probably. I guess the future belongs to one language really shines, as it run perfect on both WASM and another major VM. Currently the de facto ā€˜major VMā€™ is JVM, and probably GraalVM in the future since itā€™s showing its ambition on multiple languages.

But still I feel BEAM is superior to other main stream VMs personally since itā€™s scheduling mechanisms and message passing style. Actually Iā€™m very intrigued by LFE by I havenā€™t try it out yet. Really hope there could be some language like Typed Racket on BEAM some day.

I really hope one day I can use a full stack web framework feels like Meteor.js but written by a Lisp dialect with gradual type, and runs on both WASM and BEAM. Am I just being too greedyā€¦

For the interested Chris Seaton (TruffleRuby lead) wrote an interesting blog post about all the things possible with Graal: https://medium.com/graalvm/graalvm-ten-things-12d9111f307d

1 Like

I gave it a try. In particular I installed the node flavor and had it build an run one of our projects. It ran all the tests successfully which surprised me. But it ran them an order of magnitude slower than nodejs 6. That made it a non-starter for me.

I should mention that the above project is being replaced by an elixir project. :slight_smile:

I know the JVM pretty well (I helped port it to Linux once, signing my life away to Sun ;)), and it deserves most of the hate it receives. The virtual machine itself is, of course, a marvelous piece of Smalltalk engineering, but itā€™s too tightly coupled with a bunch of class libraries that are just plain horrible and get in the way of any effort to get not-Java running on it. Given that the performance it delivers is not really needed by most of us (wellā€¦ if weā€™d start writing decent software - the JVM does let you get away with total crap and still pump out respectable request rates), I think itā€™s a platform best avoided. And that was my opinion before Oracle got their grubby hands on it.

(end of rant)

1 Like

There is a compiler from Elixir to Javascript already. It generates extremely bloated JS but itā€™s functional. Writing a lisp dialect that compiles to Elixir is kinda trivial (just write something that transforms s expressions into Elixir AST nodes and youā€™re done).

If you do this right, then plug (and Phoenix) macros will be compatible with your lisp dialect. This gives you a web framework for free.

Read Drabā€™s source, steal the parts that interest you and find a way to compile a template so that part of it runs on the client and part of it runs on the server.

To get gradual typing, integrate with dializer. It wonā€™t be as good as typed racket but ut eill be good enough.

1 Like

The hard part here is not implementing a Lisp (even I did that once ;-)), or getting it to pump out WASM and BEAM code - thereā€™s likely to be examples of either already.

The hard part is that the BEAM is not just a VM - itā€™s more like an OS. Getting a language to target both the BEAM and ā€œregularā€ VMs is gonna be hard if you still want to make it feel like a single language beyond just the syntactic niceties. Before WASM, there have been plenty of languages made available for the browser through ā€œtranspilationā€, and my gut feeling is that they all never have become too popular because the-language-on-the-backend and the-language-on-the-browser just felt too differently. Might as well just have two languages in that case. If it doesnā€™t work for ā€œregularā€ languages, my gut feeling is that itā€™s gonna be really hard to pull off for BEAM-targeting languages.

Probably easier to port the BEAM to WASM first (and have OpenGL for your UI language so The Web can be completely ignored?)

1 Like

Certainly an interesting opinion and viewpoint, thank you!

When I say pretty good language platform I usually mean the performance that you can achieve by piggybacking on the JVM and the wide eco system it opens up for you.

Performance wise, the JRuby people still occasionally measure what performance would have looked like if they just stopped at JRuby 1.0 - iirc last time I saw the chart it had a 5x performance improvement on common benchmarks just by JVM evolution in that time. Thatā€™s wild. So much time to spend on building a language and not worry (too much) about performance.

The other point is the eco system - this might or might not be controversial but I think one of the greatest tricks Clojure pulled is being on the JVM. There are lots of LISPs, but none really made it into mainstream as there are so many fractured dialects that it was hard to build an eco system. Boom clojure, you have access to all the Java libraries. Thereā€™s nothing you donā€™t have. Yes the library interfaces might suck but you can use them and wrap them nicely.
Iā€™m not saying clojure doesnā€™t have other great features, but imo that was one of the main points to get it started. Similarly elixir also profits from the BEAM eco system.

Weā€™re also not just talking about libraries here, but also tooling - which can be quite nice on the JVM. Doing profiling work with JRuby vs. CRuby few years back was night and day.

2 Likes

Clojure seems to be a strong indication that our industry is mostly fashion-driven.

Itā€™s a not a very nice Lisp system as Java shines through in every corner and it just feels unnatural and unwieldy in that respect. One of the strengths of Lisp systems is that itā€™s Lisp all the way down (preferably on a Lisp machine, old people tell me ;-)), and if you look at pure technical merits, there probably arenā€™t that much reasons to use Clojure over other Lisp/Scheme systems. Most ā€œnativeā€ Lisp systems out there are better integrated, are very mature and fast, and if you look at their ecosystems, most of what you want is usually there (and from my tests, FFI is a breeze if you want to pull something in). These libraries probably have a nicer API to boot, as Java libraries typically are not very well-designed and even if they are, playing nice to Java doesnā€™t mean that itā€™s natural from Clojure (or Scala, or JPython, JRuby, ā€¦). Java has a very large ecosystem, but itā€™s mostly terrible stuff, frankly. Well-designed libraries are super rare. Iā€™d rather do without that ecosystem and write one or two things myself (really, for programmers we seem to be really shy about writing code; itā€™s not that hard, you knowā€¦).

Iā€™ve tried probably every language under the sun on the JVM, and none of them excite me; Clojure isnā€™t an exception. Maybe I put the bar too high?

In all honesty, if someone puts a gun at my head, say when I work at a bank, and tells me ā€œthou shalt deploy on the JVMā€, then Iā€™d sneak in Clojure. Or switch jobs ;-). Itā€™s a workable language, and likely less painful than Scala. However, I think itā€™s hardly the best or most complete Lisp system on the planet.

[side note: what ā€œkilledā€ Lisp is probably the same that ā€œkilledā€ Smalltalk - greedy language vendors rather than absence of good implementations; if you look at the pricing for Allegro and Franz, itā€™s pretty much the '80s or '90s over there. These commercial implementations seem to drive a wedge between communities - Iā€™ve witnessed that first hand in the Smalltalk world, and my guess is that here itā€™s much the same. VM work takes a backseat as people who must have the speed usually can pay the license fees, and that probably helps make room for stuff like Clojure while people working on SBCL etcetera are ā€œwhat the heck just happened?ā€]

1 Like