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!
For example TruffleRuby is based on it.
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.
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
Oracle Owns āJavascriptā, so Apple is taking down my app
https://twitter.com/benschwarz/status/986712202991169537
Understanding Oracle Java SE Licensing
Seems that .Net Core has better license than JVM
.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.
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.
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
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
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.
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)
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.
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?)
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.
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?ā]