Google, it's time – We want Scala for Android
blog.madhukaraphatak.com
blog.madhukaraphatak.com
If we're talking about official support, then I'd rather Java 8 instead. And beefing up ART even more.
The answer to Java 8+ support was "No comment".
With that said, you can already get Java 8 lambdas in Android using the retrolambda project.
Mind share ... are there any great minds left in the Java ecosystem? Doesn't feel that way.
Scala is picking up pace like anything. This has been visible to anyone following the Scala ecosystem. Not in just programmer circles, the bombardment of jobs for Scala developers in the enterprise suggests they are interested too.
I used to have very high hopes for Scala to become the next Java but at this point, I've moved on and hoping that another language will get that spot.
That's a nice bubble you seem to live in.
http://redmonk.com/sogrady/2014/06/13/language-rankings-6-14...
"The next JVM language to learn" (Java-focused survey): Scala leads comfotably with 47%.
http://zeroturnaround.com/rebellabs/interview-with-typesafe-...
Apart from that, you are completely missing the context. People are not looking for a random language, but for a language which is compatible with Java and Android, allows gradual migration and protects existing investment.
Scala is the top-contender here.
For Android, there are already more projects written in Kotlin and Clojure on Android than on Scala, so not sure why you think Scala is the "top contender".
On top of that, Scala's upcoming adoption of Java 8 means that Scala on Android is effectively dead for several years, until the Android team decides to adopt Java 8 (since they're not even on Java 7, this might be a while).
Typesafe just doesn't care about Android, why would you take such a risk to pick a language that is so poorly supported?
A better language would be something with the simplicity and power of python, but with good performance.Groovy could be one such language.
Though, I doubt it is much worse than Java these days.
Not to say this is bad, it just means you need greater discipline when writing software in Scala. A bit like C++ (yes, I went there! :-)).
I think that's what's so great about Scala, Python and other languages that mix OO and functional elements; you don't have to throw away Java and pick up Haskell, you can start experimenting with other styles as you go.
> Scala, as a programming language, tries to incorporate too many concepts
Too many concepts? Says who? How many concepts is too many? You don't have to use them all, and you can pick them up fairly easily as you go along; that's exactly how I learned the language.
> while still trying to be typesafe.
Not sure why that's contentious.
> This makes the language complex, and not an ideal candidate.
Says who? Why? Should all complex things be abandoned? I find the Android framework itself complex, personally, so should we throw that out?
This is the same Scala FUD that's always prevalent on Hacker News. "The language does too much." So what? You don't need to know all the concepts to be proficient. The language's beauty is that you can write simple code and pick up the concepts as you go along. Library modularity generally means that you don't need to get into the deep end of the language unless you want to. Scala is an expressive language. That's an intentional design decision that makes it flexible. It is not a drawback. It does not make it overcomplicated for a beginner.
Says at least me and the OP, and probably others... I haven't put a ton of time into learning Scala and only occasionally interact with it, but in that capacity I'd definitely say I find it a bit intimidating and someone hard to read. Certainly there are many ways to write Scala, and a Java-like style is doable, but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators that aren't immediately interpretable by people not familiar with the language.
Whether legibility from non-experts is important is absolutely a matter of opinion and personal taste (it's a clear source of disagreement between the Python and Ruby communities as well), but if you're someone who thinks it's an important property for languages that get widespread adoption to have (and I am), looking at Scala code as it seems to typically be written would give you (or at least gives me) pause. I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala. I don't think they fill the same niche, as the poster seems to be advocating that they could.
Gut feeling, Scala is the new Perl. At least with respect to 'idiomatic' Scala/Perl encouraging a terseness, as well as a fairly deep/loyal (if small) fan base. Also, many of the use cases where the language shines tend to be non-mainstream - usually other languages handle mundane 'every day' use cases differently, perhaps more verbosely, but also with a lot more developers on board.
Just a thought that popped in to my head. I've no doubt I've offended the very core of many Scala and Perl devs out there just now. ;)
This is not idiomatic Scala.
http://docs.scala-lang.org/style/naming-conventions.html#sym...
> Avoid! [...] As a general rule, symbolic method names should be well-understood and self documenting in nature. The rule of thumb is as follows: if you need to explain what the method does, then it should have a real, descriptive name rather than a symbols. There are some very rare cases where it is acceptable to invent new symbolic method names. Odds are, your API is not one of those cases!
Looking at the major Scala libraries and frameworks today, I don't see a ton of symbolic operators in use. Akka just has ! and ? (both of which have very obvious uses once you understand actors), Play only uses them for iteratees (which most devs will never have to think about, plus it provides named equivalents for all of them), SBT has been cutting back. Outside of scalaz, the problem seems to be under control.
You realize that Swift not only resembles Scala syntax closely, but also adopts many of the same concepts?
Yes, you do. We heard this kind of argument with C++ twenty years ago. You can choose to ignore huge portions of the language for your personal use, but once you start working on a team, you will have to know the entire language.
That's not a fact -- its not even a fact claim -- its a value judgement. "Too many", except as sloppy terminology for exceeding an objective criteria, is inherently a value-judgement qualifier.
But usually it's like:
"so which concept do you think is superfluous?"
"crickets"
It gives tools to those who need it in a simple and elegant way, why is this a problem?
Use the features you find useful, don't use what you don't want to.
(Of course you can do more complex things in Scala, taking advantage of the powerful type system. But you don't have to if you don't want to)
For something like Android, running Groovy with CompileStatic enabled by default would make a lot of sense.
In theory, but in practise virtually everyone uses the dynamic typing only. Groovy's really only used with Grails and for testing Java classes.
> Android, running Groovy with CompileStatic enabled by default would make a lot of sense
Unlike other statically-typed languages, Groovy's CompileStatic code was written by only one person and having it be the default would expose all the bugs.
Why ? is it a social thing? or a technical thing?
And shortly after that, he became a full time contributor to the Kotlin language.
Android needs a statically typed language, but Groovy's dynamically typed, and the statically typed portions available via annotations since version 2.0 isn't really used much. Groovy's still usable for its original use case of manipulating and testing Java objects, and with Grails, but the more recently promoted stuff isn't being used in favor of other options, and even Gradle seems to have been totally rewritten in Java for Gradle 2.0. I suspect Gradle will soon open its configuration as an API so any language can be used with it.
Also, it has excellent IDE support, since JetBrains is behind it.
For what Google is doing their choices were basically C++ or Java, there is no other embedded, performant option that hits mass quantities of developers worldwide. Every other language is either too niche, or not performant enough, or doesn't have the features you would want. Sure, I guess they could have done C#, but I'm pretty sure Google hates Microsoft, so that's not going to happen.
iOS only has Objective-C because of NextStep and OS X. Otherwise, it could very easily have had C++ or Java. Blackberry ended up with C++ for their native toolkit.
Has there been a significant mobile platform that wasn't C++ or Java that doesn't have some historical reason like Obj-C has behind it?
The thing about Java and C++ is that they themselves are around for historical reasons. Far better languages have already been proven out. But, it will take a major industry player to move the masses forward on this. Apple's Swift effort gives hope on this.
For what they do, C and C++ don't really have serious challengers yet, not that there aren't some promising contenders.
Obj-C to Swift won't happen overnight at Apple either, but it is much more likely to happen because they've been gradually working towards it for years now with LLVM and such.
Only if you define "what they do" in a way that makes that a trivial tautology (e.g., as "things for which C and C++ don;t really have serious challengers"). Over time, a lot of serious challengers have arisen and competed with (and even displaced) C and C++ in areas where those languages have been widely used. There may still be areas where they don't have serious competition, but those areas keep getting smaller.
* As an aside, for beginner programmers I think that asking them to use a Lisp is far more conceptually challenging than using the basic syntax of Scala (could be wrong though... I don't know Clojure, but I found Common Lisp fairly easy to understand yet know that many beginners do not).
I think a platform's primary language should be accessible. It is an unfortunate fact that the stuff that most people only know about programming using some object oriented imperative language. People find it harder to hobby with unfamiliar styles, and it is hard to find leverage within your organization to go into unknown territory. If it isn't a popular widely known language (Java) it should at least resemble popular widely known languages (Swift). Give people a piece of Java or Swift code, and they can read it. Give people a piece of Scala code, and they usually cannot.
Scala can be an accessible language; its imperative syntax is really nice. But Scala is not an accessible language in that idiomatic real-world Scala and most of its libraries are written in a wholly unfamiliar style. Powerful, yes. People should learn it, yes. But if Scala comes to Android it will only serve to make the platform seem less accessible. And that's a much bigger downside than whatever expressivity Android Java currently lacks.
Scala can't even properly be a primary language in parallel to Java at the moment. Swift is just a better syntax for expressing idiomatic Objective C programs. Good Swift programs should look mostly like good Objective C programs with a different syntax - Swift has been made for this purpose [1]. Scala is not a better syntax for expressing idiomatic Java programs. Despite backwards compatibility, good Scala programs look very different to good Java programs. This means that Google cannot present them as equivalents. The Android platform APIs heavily promotes mutability which makes writing idiomatic Scala code for Android a pain in the ass. Should Google ask people to write non-idiomatic code for their new primary language, or should Google provide new APIs for their new primary language?
I dislike Java very much. But I think it's a great language for Android, because everyone can do it and that makes the platform accessible. There's only one other language I can even remotely imagine in its place, and that's Dart. And that's not happening either.
In the meantime, making Scala run on Android is perfectly doable. That is good enough for me.
[1]: I'm aware that this comparison doesn't do Swift as much justice as it should.
You realize that Swift not only resembles Scala syntax closely, but also adopts many of the same concepts?
Oh, right. Just the usual Scala bashing ... I think you have forgotten to mention C++.
If you think that superficial syntax comparison is a fair comparison of the two languages, then you haven't written idiomatic Scala code. It's true that Swift looks a lot like imperative Scala. But that means nothing as nobody writes or should want to write imperative Scala.
> Oh, right. Just the usual Scala bashing ... I think you have forgotten to mention C++.
Did you miss the part where I said I wrote mostly Scala for the last couple of months? Look at my post history, I love Scala.
This is a very important point. There is a lot of ambivalence about Scala in the non Android world already, it's naive to think this ambivalence would completely go away on Android. The same problems that are crippling Scala's adoption in the non Android world will be present on Android.
Certain Scala libraries are indeed not accessible. But the trend is in the right direction (there are better alternatives to requests now, and even scalaz has become less symbolic in recent releases). If Google were to provide the same APIs and sample programs that they currently do, those programs would be as accessible as they currently are - probably more so, given Scala's cleaner syntax. You say this could make Android less accessible. Maybe. But it could also make Scala more accessible, providing a whole new class of developers with a stepping-stone from somewhere very familiar towards these valuable high-level features.
As the Python folks say, a good language should make easy things easy and hard things possible. IMO Scala does both halves better than Java. It's just that so far, people have mostly been using it for hard things.
The problem with Scala is not symbols or legibility (although that used to be a major problem), but the fact that its programming style tends to be mostly functional. Monads, for-sugar, implicits, immutability: stuff everyone should master but in practice very few do.
> You say this could make Android less accessible. Maybe. But it could also make Scala more accessible, providing a whole new class of developers with a stepping-stone from somewhere very familiar towards these valuable high-level features.
The Android developers unfortunately have no interest in making Scala more accessible. They have an interest in making Android more accessible. They would have to make a lot of sacrifices to make Scala a primary language for Android, and the benefits would be rather small from their perspective.
Scala's killer apps are on the server side. That seems to be going quite well so far.
I think just fixing their god-damn bugs would be enough to make people happy.
Accessible is one thing, but not the only thing that matters, particularly as the platform matures. If using Scala makes developers more productive, or leads them to write less buggy code, that could be a huge advantage for Android.
And you need to do that for what? Because Java is too verbose? I hate (real-world) Java as much as the next guy but I don't have any illusions on this because the argument just doesn't add up and the effort doesn't seem worth it by a big margin. It would be much more feasible if Google would release an improved Android APIv2 with stronger immutability, first-class support for Java 8 and its features (lambdas, Optionals) and no 64k DEX limit. That would be a huge improvement for both Java and Scala Android devleopers, and it would also be feasible.
Ideally, it would compile to Dalvik/ART or ARM. It would use something like PySonar to infer types or use annotations to be able to use native types when possible (for speed & correctness). When the type isn't given or can't be deduced, it would fallback to boxed objects (like Nuitka does, in the way the offically C-Python keeps its objects in memory).
But that is not neccessary, all that is needed is a decent wrapper to the Android API for Python, and some packaging support. It is now already possible to compile Python for Android to include it in your app. What I'd like to be able to do is to write the whole thing in Python (+ a GUI design tool maybe).
I already see some people saying, that's not possible, because an interpreted language uses too much resources (CPU, memory, esp. battery) for mobile. Well, 90% of the apps I use are not computationally expensive. The consume battery mainly via network access, and via the screen, both of which is independent of the language or runtime used. And when they are doing something computationally intensive, it is usually the layout and drawing of the GUI - most of which is done by the native framework anyway. Most apps are literally just fancy listboxes and details pages, with a database and a web backend. (The great exception are games, of course.) For these apps, a rapid development language like Python (or Javascript, or heck, a new VB) would be great, ideally augmented by good tooling. And if you have something CPU intensive (map routing, image processing, complex translation etc.), you'll just write it in a C library anyway.
Best you'll get, and quite good.
Google IO 2014, Android development fireside:
https://www.google.com/events/io/schedule/session/85311b0e-7...
The answer to this request is "Java is the official Android development language".
In the meantime, the android tools team is hard at work improving the usage of Java on Android. Some examples that should be coming soon : -the end of the 65k limit. -enums with int performances/costs, at least for basic cases. -code hot-swaping (for 2015).
As such, any language they see announced as safer than C and C++ must be VM based.
I don't mean disrespect when I say niche. I just mean in terms of community, Scala seems to more diversified as it gets used in variety of fields compared to Dart and Go. This is just view of mine.
There's also the fact that Typesafe doesn't care about Android so even if your current app works on Android, a future version of the compiler might make it blow up on the phone after you recompile it.
Unfortunately, the Ceylon team doesn't seem to be interested in supporting Android either.
Which leaves Kotlin, as a reasonable option for non-Java development on Android.
At any rate, don't expect any help from Google about Scala, they're not even supporting their own non-Java languages there (Go, Dart).
Yes, it's the same problem why compiling Scala to JavaScript is impossible ... oh wait!
In both cases the standard library overhead is a few dozens of kB! The horror!
That's why nobody is using Scala.js or Scala-on-Android for anything serious ... oh wait!
That's already happening.
The web (scala-internals, scala-users, stackoverflow) is filled with threads of people trying to run their Scala code on Android and being mystified by fatal errors from Dalvik or DEX generation simply dying on them.
No. Not even close.
There is exactly one known issue with Dalvik's limit of 64k methods, which requires running ProGuard before putting it on the app store (which is standard procedure for all apps).
This limit is hit by plenty of large apps.
I am sure most android devs rather have a major ramp up of the Android APIs rather than switching the programming language. The real problem with Android is the ungainly APIs and how very cumbersome it is to develop anything reasonable.
These facts actually can make porting a performance application to scala quite a job!
[1]: http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded... [2]: http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...
Somewhat different setup though. Instead of a Java-replacement language on top of a JVM, I believe it's compiling to native code. The intention seems to be to target "logic-heavy" apps where a smaller portion of the code is UI. You still write the UI in each platform's "normal" way (Java on Android, Obj-C on iOS), but call out to Lisp for the real work. I'm not 100% sure on this part, but I believe that's done on Android via the NDK route, not Dalvik/ART. No idea what happens on iOS.
At a guess, I'd say that with Java 8+ they'd have to fix that. Probably why they said "no comment" as pjmlp pointed out (https://news.ycombinator.com/item?id=8192614).
In theory, it should be possible to write code on the Android platform using any JVM language. Groovy, Scala, Clojure, Kotlin, etc. There are hiccups to that right now but you can hack your way to it generally.
But Android's APIs are going to stay in Java. That is a lot different than Apple's move to Swift, where the platform itself is moving to the new language.
It's on compile time and not at run time. It injects release/retain calls between acquiring ownership and relinquishing ownership.
I could be wrong but I don't think they added GC to Swift, as Objective-C (at least not on Mac OS) doesn't have it.
EDIT: They got rid of the GC on Mac OS as well. They use ARC there as well just like iOS.
2. Even if Google changes the primary development languages of Android where do you go to ask developers to port their Java libraries, technical bloggers to update their blogs with Scala code or change thousands of questions on SO.
Documentation/Q&A created around Java/Android is equally important.
How does Scala solve any of the problems with Java?
It has a generics system that makes a lot more sense (allowing covariant/contravariant types, rather than forcing use-site variance everywhere).
Case classes are wonderful for making simple data classes easy to read (and write).
Honestly Scala is all about solving the pain points with Java, so just look at anything that's been written about it. http://www.scala-lang.org/
Does it actually solve any real problems?
Does it fix GC performance? Does it fix API issues? Does it remove the need for JNI bindings to native code?
No?
Implicits make it much easier to deal with API issues.
These problems are not solvable by any language.
What is actually happening: "There is however, a subset of Android apps written against a much smaller C-based API surface provided in the Android NDK: Games. It is feasible to build Go support for Android providing the equivalent features found in the NDK."
Source: parent link (https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...)
Writing JNI bridges for everything and reboxing costs would be prohibitive.
In theory, they could make ART allow for both the Java code and the Go code to work on Android, no? So we could have Google push new app development to Go, while they deprecate Java over the next 5 years (after Go support is out).
But to get developers to write Go, they also need a significant market share of Android L/ART-enabled devices, like over 50 percent, which will take 2-3 years to arrive there anyway. They can use this time gap to port Android APIs to Go, and when ART is on 50-70 percent of the devices, announce that developers can now write Android apps in Go, too (for Android L+ only).
They could announce it at the release of Android N (the one after M). By then Go 2.0 will probably be out, too, so they can support 2.0 on Android from the beginning, especially if they plan Go 2.0 to have some pretty major incompatibilities with 1.x. In the meantime, the Go team could also work on some "made for Android" features for Go 2.0, to make Go more optimized for Android. By then, they'd probably only have to support ARMv8, too (preferable, I think). So they can target only 64-bit ARMv8 hardware with Go (from what I hear Go works better with 64-bit hardware anyway).
I think Google can do this. They just need to plan it out. Three years is probably a reasonable time period for this.
They are doing it for games too, great.