Yep, it is easier to make languages target DEX than suffer the pain of the NDK.
They not only advise against it, they make it really uncomfortable for us to use it (vs iOS and WP experience).
Why do you say that? Plenty of Android apps use non-trivial amounts of C/C++ code, and Dropbox has a tool called Djinni that can automatically generate JNI glue code. My guess is that if it's feasible to use pure Dex bytecode, then debugging is easier (because there's only one kind of call stack), memory can be managed more effectively (because the Dalvik/ART garbage collector can manage everything), and performance isn't impacted by the overhead of JNI. But I have nothing to back that up.
- The bug tracker is full of NDK issues
- GDB works, eventually. If one has the right set of versions and mobile firmware
- Integration with the first official IDE (Eclipse CDT) kind of worked, after one turned off indexers, did a few plugin customizations, and even then not really
- When Android Studio was announced, silence ensued about NDK future. When Jetbrains announced CLion, there was the hope that it might came to Android Studio, still silent all the way up to Google IO 2015.
- No pre-defined templates for mixed code applications
- Even today Gradle support for NDK builds is flaky and not final. I am yet to be able to have the samples build out of the box.
- The set of official C++ libraries is quite limited, most game related APIs are exposed. Even C++ libraries used by the Java layers like Skia are not exposed to the NDK.
- By limiting NDK to a few basic POSIX APIs and Android game related APIs, everyone has to pack into their APK everything from JNI wrappers, image loaders, network access, the whole stuff.
Now compare this with using C++ in iOS with help of Objective-C++ or on Windows Phone with help of C++/CX.
First class tooling support, mixed debugging that works and no need to keep on writing wrappers.
Even Microsoft's tooling for Android NDK is looking better than what Google does for their own platform.
As for Djinni, I am yet to make it work on Windows.
So what does this look like in practice? Genuinely curious :-)
So, you get the same benefits of the languages that target other VMs like JVM, CLR, BEAM and so on.
As long as, the language semantics can map into the VM semantics, all the libraries and platform tooling are available without the need of writing wrappers.
True, that is a big "as long as", but it still is less problematic than going through the current state of the NDK.
That is the approach take by Elements for their tools (http://www.elementscompiler.com), for example.