Axum is different because it is designed for a specific domain by the same people that are designing .NET. This means changes to the CLR may be pushed forward to accommodate features in Axum. I don't know if the tail call instruction in the CLR was added because of F#, or because of the research they did while trying to compile Haskell on top of .NET, but it's there.
The problem with the JVM is that there isn't a centralized effort for those multiple languages. You can slap any interpreter on top of any other interpreter and then say that "multiple languages are available", but that won't make it useful.
Although new features are pushed in the OpenJDK to make dynamic invocation of methods lighter, more infrastructure is needed ... like a common MOP used for communication between these languages (like the DLR). There's a strong lack of leadership between the language implementors working with the JVM, because SUN couldn't care less about it and everybody is scared of new features in Java-land.
Axum is different because it is designed for a specific domain by the same people that are designing .NET. This means changes to the CLR may be pushed forward to accommodate features in Axum. I don't know if the tail call instruction in the CLR was added because of F#, or because of the research they did while trying to compile Haskell on top of .NET, but it's there.
The problem with the JVM is that there isn't a centralized effort for those multiple languages. You can slap any interpreter on top of any other interpreter and then say that "multiple languages are available", but that won't make it useful.
Although new features are pushed in the OpenJDK to make dynamic invocation of methods lighter, more infrastructure is needed ... like a common MOP used for communication between these languages (like the DLR). There's a strong lack of leadership between the language implementors working with the JVM, because SUN couldn't care less about it and everybody is scared of new features in Java-land.