Swift and Kotin manage to capture the perfect amount of "a few new features but not too many" of all languages I've played with these past ten years.
They are both the perfect example of languages that hit the right compromise in many dimensions.
The code they write is less about implementing some business functionality in the most elegant way possible. But rather it's an exercise in who can use the most obscure parts of the language.
And unfortunately there are far too many obscure parts.
Most Scala developers are in the A bracket. The experts are in the L. The code written by either is so different they could almost be different languages. You don't get this sort of split in Swift, Java etc.
All languages have this. You could write more or less the same list for Swift or Java with minimal changes.
Again, do you have any actual experience with this, or is this just your assumption? Because I have never seen this issue in the wild.
At the extreme of the first group you'd have people for whom it seemed like every problem was best solved with a higher-kinded-type. And while it might well have been technically (and mathematically) elegant, the rest of the team was left scratching their heads trying to understand it.
I think it's rather more likely that you simply don't understand why they're using the more obscure parts of the language on any given problem. They're probably trying to rule out certain invalid uses as type errors, which is typically encouraged in the more advanced typed languages.
The features are great for people writing libraries, but general purpose code should usually only need a subset.
Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)
Why is that a problem? Different people/teams will have different needs.
If I'm working on a problem where generics is a good fit and bob across the office is working on more business code where it isn't a good fit then it makes sense that we would both be using a different subset of the language.
In the case of Scala:
If you ever browse the standard collections library you'll run into a lot of different variance rules and implicit constraints. It is quite hard to really understand the collections library if you don't get your head around those.
If you want to use Spray for anything more complex than they spell out in their examples, then you need to understand their magnet pattern.
If you want to be able to debug a problem in Slick then you'll need to understand shapeless.
If you ever go anywhere near scalaz then you'll need to understand every esoteric symbol and operator in Scala, as well as be able to read and understand Haskell (because the patterns and types in Scalaz are often explained by reference to the Haskell equivalent)
Yes, I can set rules for my own team about what features we use internally, but I want my team to at least broadly understand the syntax and patterns used in the APIs that they interface with, which means you need to either read & understand most of the features that you aren't using internally, or avoid a very large percentage of the scala ecosystem.
Please have a serious look at Swift. I don't think this claim stands up to any kind of scrutiny.
Swift is more like C++ than anything else in terms of features, Kotlin has roughly the same amount of features as Scala but more special-cased ones. Kotlin solves one problem well, and only that one: If you want to write Java, but want it to be a bit less verbose, then Kotlin is perfect.
Well for it's intended audience it's exactly what they want I guess, same could be said for Swift IMO. That said, Swift definitely has boarder appeal.
Maybe this is more of a case of an ideal feature set as envisioned by Odersky vs' Lattner, idk. Either way different people look for different things in a language and that's all I'm saying really.
I think there is large audience of people who want the best OOP tools, or the best FP tools or both.
The Scala community, on the other hand, got hijacked by a bunch of Haskell neckbeards who spew executable ASCII art over every codebase they get their hands on. The formation of the Scala Center feels like a response to this -- an effort to "retake" Scala.
You almost never need to deal with Java except if you want to.
Plus, unlike C/Ruby/Python/.NET you get a JS backend that actually works¹ (unlike mess like GWT, or various other languages).
¹ In the sense of: Scala.js is stable, mature and production-ready. You can use it, save a lot of time, share a lot of code, use mny of the libraries you already know, enjoy great IDE and tooling support, use it in real projects and make money with it.
Deals with SDK dependencies automatically, typed resources and views, better Instant Run, ProGuard caching, extremely low overhead, fast compiles, ...
Very slow compiles (contrary to what you claim).
Language style encourages constructs that cause GC spikes, closures are not low overhead
SDK dependencies automatically meaning what? The thing AS does for imports from AppCompat and co?
Better instant run?
Method count forces multidex insanely early into
development and for people who want the best UX that
alone is a show stopper.
Here is a data point from a small example app written in multiple languages: https://github.com/SidneyXu/AndroidDemoIn4Languages
If you need multidex (you probably don't), it's a single setting away.
Very slow compiles (contrary to what you claim).
testQuick is also amazing as it runs only the tests that have failed, haven't run before or depended on code you just changed: http://www.scala-sbt.org/0.12.4/docs/Detailed-Topics/Testing...
Language style encourages constructs that cause GC
spikes, closures are not low overhead
SDK dependencies automatically meaning what? The thing AS
does for imports from AppCompat and co?
Better instant run?
...
And then you have goodies like typed resources: http://scala-android.org/tips_and_tricks-typed_resources/
Or the automated Gradle config import which means you don't need to do configure anything except adding the plugin: https://github.com/scala-android/sbt-android/blob/master/GRA...
Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)
Proguard removes most of those methods, but you'll still need multidex for any non-proguard build like tests and debug builds.
And if you do grow an app past the point of being trivial as that example is Proguard gains will not be nearly as drastic
Multidex on pre-Lollipop ruins app start time, and only very specific types of apps can go to targeting minSdk 21
Predexing with Multidexing and Proguard are also slow for development for non-trivial apps. Your measure of "how long it takes to pick up a phone" is far from scientific", but to compare, not a single app non-trivial app I've worked on is so simple that installing a fully compiled APK over ADB would be less than a 5-10 second process.
That would leave 0-5 seconds for the entire app to build, proguard, and predex (with multidex). Not possible.
Gradle 2.2+ has the SDK download feature, and before that everyone I know was already using "sdk-manager-plugin", not even for convenience on dev machines (it's not that often that SDKs come out after all), but for CI builds.
Protify is not Scala exclusive if one really wants to use it, but JRebel also has a more mature Instant Run solution. Instant Run type features are useful for very specific types of changes that I don't find to be very common anyways. The layout editor + proper use of the edit mode flag and the tools namespace can already reliably replicate half of what I see instant run and co used for, with the added benefit of having even speedier development cycles.
Also: Typed resources are part of Google's databinding library, not that I know anyone who uses findViewById when we have libraries like Butterknife
To me using languages other than Java for Android dev is a risk about balancing mindshare, UX, and continued support for workflows in Android.
Kotlin has mind share, UX doesn't suffer, and it's gotten big enough that while Google has not come out officially and said it's supported, it's mindshare is large enough that Google knows that efforts like Jack and Jill cannot adversely affect workflows (The transformation API is great example, if projects like Realm, Dagger, and co didn't have so much mindshare I doubt it'd be much of a priority for the project).
Scala on Android has a much smaller mind share and is much less proven despite it's maturity, can kill UX a lot easier because of an insanely method-expensive core library which brings in thousands of methods once you use certain features, and is has not gained enough traction to to have to work around Google's plans than with them.
To me the proof is in the pudding, if there were real gains to be had with Scala it'd have more traction than it does.
Method count has nothing to do with size.
Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)
And if you do grow an app past the point of being trivial as that example is Proguard
gains will not be nearly as drastic
You pay for exactly the stuff you are using, just like with every other library.
Your measure of "how long it takes to pick up a phone" is far from scientific", but
to compare, not a single app[sic] non-trivial app I've worked on is so simple that
installing a fully compiled APK over ADB would be less than a 5-10 second process.
That would leave 0-5 seconds for the entire app to build, proguard, and predex (with
multidex). Not possible.
To me the proof is in the pudding, if there were real gains to be had with Scala it'd
have more traction than it does.