Take spark, for instance. You run into extreme performance issues the second your data has to be serialized to cross the py4j gap. An many essential parts of its API require scala/java (presumably Kotlin ought to work as well).
Similar situations occur all across the big data and cloud realm, with python. And then even still today.. you'll run into situations where whizzbang data science ml library that solves your exact problem.. for some reason is python 2.7 only. Thankfully that situation is getting rarer (there really isn't an excuse for it today) - but its still there.
In any case, a "not-java" language that can talk java is freakin amazing, in my book (Scala doesn't scratch my itch there - it's far too clever - had enough of that with perl back in the day).
I don't understand why this is such a big draw for people when literally any jvm language[1] has this feature. Languages like jython, ABCL, clojure, jruby, groovy, and perl6. Kotlin is certainly not unique in this regard.
Some of the languages you mention come with serious compromises when used on the JVM, like Jython and Jruby - decent portions of their ecosystems are implemented in C - and hence won't work on the JVM.
It's notable that projects like spark could have used Jython for its JVM/python interop, but chose py4j instead, consigning pyspark to some rather abysmal performance penalties under many conditions.
I'm not sure either. Your comment seems perfectly legitemate to me...
Clojure is a bunch simpler than Scala, many Python programmers are quick to pick it up. The dynamic nature and interactive prompt is all there.
If you look at Norvig's Python-Lisp comparison table at http://norvig.com/python-lisp.html - all the red cells (where Lisp lost to Python) are fixed in Clojure.
To me "complicated" means that the rules of a system require a lot of information to describe, i.e. it has a lot of special cases and caveats to learn. Whereas "complex" is more about the variety of emergent patterns in a system which are necessary to understand it and interact with it effectively.
As an example, rules of Go are very simple, but we probably wouldn't call it a simple game. In contrast, the rules of Chess are rather more involved, with quite a few special cases. Both games can be called "complex", but I'd also say that Chess is more complicated.
So using these terms, it sounds like you're saying Scala is less complicated than Kotlin, whereas the parent is perhaps saying that Kotlin is less complex?
That being said, having gone through at least one book, and have read lots of code - I still find it very difficult to parse in my brain.
It feels more complex to me, because there seems like there are so many implicit things going on, where something like Kotlin makes efforts to be explicit (yet still strikes a nice level of conciseness). But that could also be my inexperience with scala.
Having different syntax for different kinds of effect as Kotlin does could be seen as more explicit I guess, but I find it actually makes it harder to work with - you have a lot more syntax to keep in your head, and you can't write generic code that works with multiple different effects. Other than that I don't think there's anything more explicit in Kotlin, and some things - error handling in particular - are definitely less explicit.
Currently Python took a niche between quick ad-hoc exploration tasks (land of R) and production pipelines (land of JVM/C#/C++), but for large pipelines it's not so suitable IMO.
That's why I like dynamic typing. Coupled with Python's type annotations for hard cases and good documentation, dynamic typing allows you to go further by reducing cognitive load.
There are .NET CUDA implementations as well.
For example, on Android, Java is the name of the game, beyond 3D rendering and audio codecs, the NDK is quite useless as everything else is exposed behind JNI calls.