I don't think I would call Scala's adoption "massive", but for the sake of this discussion, let's say I agree. Now, Scala has many features; which of them, do you think, are the largest contributors to that adoption? Hindley-Milner? Implicits? Type-safe macros?
I'd argue that it's lambdas, traits (both now in Java 8), and reduced boilerplate for Java beans; also, maybe pattern matching. Now, all of those features are in Kotlin, which has a far simpler (though less expressive, even though that hasn't been proven to be a major problem) type system and much, much smoother integration with Java.
Tuples, Pattern matching, Structural types, Implicits, Collections framework etc. etc.
One of the biggest advantages of Scala is the community. Java has a culture of excessive over-engineering, boilerplate and XML. The Scala community tends to think more in terms of a fresh start, rather than seeing themselves as a Java extension. The extreme resistance to change within the Java community and unwillingness to look beyond the only tool in their toolbox makes are also major issues. Every feature is unnecessary complexity and evil until it gets added to Java, and then suddenly the "evil" feature in C# or Scala is suddenly an amazing new "innovation".
> Now, Scala has many features; which of them, do you think, are the largest contributors to that adoption?
Low-boilerplate syntax is certainly a big plus, but I think the biggest feature of scala is that it makes it easier to handle cross-cutting concerns without stepping out of the language. Concretely: a consistent, natural syntax for async calls; better ways of handling errors (validation monad), dependency injection without reflection. And almost as important is the ability to construct DSLs in the language itself (e.g. spray's routing syntax); I know at least one company where this was the primary rationale for adopting scala.
So I think higher-kinded types are a key feature, even if to start with users are only using the libraries built on top of them (you can do specific bodges like C#'s async/await without them, but to have a consistent, extensible syntax that does collections, async calls, and error handling you really need the higher level of abstraction), as are implicits and dependent types (both vital for DSLs). And there were certainly times when I found myself wishing for macros before they existed. Some users might come for the syntax or the traits (though I think error-handling and good async abstractions are at least as appealing, particularly in finance where a lot of the adoption is happening), but you stay for the type system.
If you spent a few minutes actually using Scala instead of trying to bash and hate it in every thread, you'd know that Scala doesn't use HM.
Scala killer feature is the assurance that developers can express the things they want, unlike Java and C# where the compiler starts acting like an angry child as soon as I want to do anything slightly more elaborate.
That won't be changing anytime soon.
> a far simpler (though less expressive, even though that hasn't been proven to be a major problem) type system
The lack of typeclasses is a non-major problem? I would say it is an absolute dealbreaker.
Anyway, in what sense it is "far simpler"? Most of the complexity comes from dealing with Java's broken ideas. If Kotlin wants interop, it can't ignore that.
> Scala killer feature is the assurance that developers can express the things they want
If you mean "some developers" or alternatively "some of the things they want" (this set of things being strictly greater than the set of things available in Java), I'll agree with you.
I'd argue that it's lambdas, traits (both now in Java 8), and reduced boilerplate for Java beans; also, maybe pattern matching. Now, all of those features are in Kotlin, which has a far simpler (though less expressive, even though that hasn't been proven to be a major problem) type system and much, much smoother integration with Java.