The ability to mix languages is really underrated I think. Today you can toss a ball of Objective-C/C, C++, and Swift at clang and it’ll figure it out and spit out a single binary. That’s kinda crazy, and it lets you use whichever makes the most sense for each component of your app and gives you the ability to leverage a staggering number of libraries between the four.

It’s a stark contrast to e.g. Android world where making use of languages/libraries outside of the JVM bubble is technically possible but not necessarily a good idea in many if not most situations due to the caveats involved.

That is by design, of course it doesn't work easily, people keep trying to fit a square peg into a round hole.

From the official NDK documentation.

"The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps. However, the NDK can be useful for cases in which you need to do one or more of the following:

- Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

- Reuse your own or other developers' C or C++ libraries. "

Anyone that keeps not understanding that point of view naturally run into walls that Android team has no plans to ever change.

Even so, it’s quite limiting and makes it difficult for e.g. non-JVM UI libraries to exist on Android. No other popular platform has this issue.

Mostly because Android was on the forefront that is about time to move from C and C++ for the whole application stack.

Note that you also aren't without issues on Apple platforms if the language doesn't plug into the Objective-C or Swift runtimes in some form.

Likewise on Windows if the language isn't able to talk .NET or COM/WinRT.

>languages/libraries outside of the JVM bubble is technically possible

Isn't Truffle/GraalVM an attempt to bring in more interpreted languages under the JVM?

No, that is a side effect.

Truffle/GraalVM is the evolution of projects like MaximeVM and JikesRVM, of having a meta-circular JVM, with a compiler development toolchain.

Naturally by having a compiler development toolchain, there is also interest on going forward beyond just Java programming language, and see which other languages it can handle.

JVM itself already had a more friendly take on dynamic languages, following the .NET DLR efforts, with invokedynamic on the JVM (Java 7). Which was later also used as mechanism to implement lambdas due to the way as invokedynamic works, it can be faster and less resource hungry than the anonymous class approach many think is used instead.