Graal and Truffle could accelerate programming language design
There&#x27;s actually a fairly long history of cross-language VMs, with various degrees of success.  What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM.  So LLVM works well as long as your language is <i>mostly</i> like C (C, C++, Objective-C, Rust, Swift).  Parrot works if you language is <i>mostly</i> like Perl 6 (Perl, Python, PHP, Ruby).  .NET works if your language is mostly like C# (C#, F#, Boo, IronPython).  The JVM works if your language is mostly like Java (Java, Clojure, Scala, Kotlin).  Even PyPy has frontends for Ruby, PHP, Smalltalk, and Prolog.<p>&quot;Mostly&quot; in this case means semantically, not syntactically.  It&#x27;s things like concurrency model; floating point behavior; memory layout; FFI; semantics of basic libraries; performance characteristics; and level of dynamism.  You can write a Python frontend for both the JVM and CLR, and it will <i>look</i> like Python but <i>act</i> like Java and .NET, respectively, with no guarantee that native CPython libraries will work on it.<p>The problem is that this is where basically all the interesting language-design research is.  I wouldn&#x27;t use Rust for the syntax; I&#x27;d use it because I want properties like complete memory safety, manual control over memory allocation, easy (and fast!) access to C libraries, and short startup time.  These are all things that Truffle explicitly does <i>not</i> deliver.<p>It&#x27;s a great tool if you work in the JVM ecosystem and want to play around as a language designer.  But most of the interesting languages lately have created their own ecosystems, and they succeed by solving problems so fundamental that people will put up with having to learn a new ecosystem to gain the benefits they offer.