Um, people have already been able to use Scala to make Android applications. Just about anything that doesn't require dynamically generated JVM bytecode can manage, difficult and error-prone as it is.
If we're talking about official support, then I'd rather Java 8 instead. And beefing up ART even more.
To me, Scala just feels like a mess. Java 8 isn't as modern as I'd like, but just having lambda expressions and declarative syntax would boost the quality of life so much.
Technically speaking, Android doesn't fully support Java 6. It's only a partial implementation of Java, since Java is overweight. The Android team has been adding requested features to the SDK in piecemeal form.
With that said, you can already get Java 8 lambdas in Android using the retrolambda project.
How does this work with a jar which contains classes using java8 features? Will it work in this situation or is it only for classes to be compiled? Can retrolambda be applied in other situations to keep the java version at 6 but use java 8 features?
Who's "we"? How about we ask Google to focus on things the vast majority of Android developers actually want? Java 7/8 comes to mind. Even if we're looking for just an alternative Android dev language Scala probably wouldn't even be in the top 10.
Well I'll immediately admit my top 10 comment wasn't exactly based on comprehensive research and polling on the subject. That said I doubt that if such a poll would happen the results would place Scala anywhere near the top. There are just very few upsides for Google to do so. Their main reason for adding language support would be to broaden the developer base that is able to create Android applications and how many Scala developers do you know that aren't fluent in Java?
As a new Android developer Scala wouldn't remotely have come to my mind as a feature I wanted anytime soon. The Android Studio is still in beta, the ability to test different platforms with the simulator is less than great (poor) experience still on a MacBook Pro, and the vast majority of developers come out with iOS versions of their products before Android. Those three alone need massive attention before I would even remotely want Google to focus resources on Scala development.
Scala and Groovy are used for two totally different use cases. Scala is used instead of Java as a systems language for building systems, whereas Groovy is used as well as Java for testing Java classes or calling them from Grails. In theory we could use Groovy as the dynamic language for Scala, but because of its type inference and syntactic tersity Scala doesn't need a Groovy.
All the various language surveys that have come up these past months (RedMonk, TIOBE, job boards, github popularity, etc...) put Scala in a distant #30-50 slot. Certainly not in the top 90% mainstream languages.
Please, let's be rational about this. A new language takes time to gain widespread use. Or are you telling me that Go, Scala, <put your favorite new hotness> all account for nothing? We the developer community are in a transition phase. The advancements will become mainstream but it will take time.
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.
Sure, languages take a very long time to gain adoption. Scala has been around for ten years and is still showing very little adoption while Clojure and more recently Ceylon are already receiving a lot of attention.
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.
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.
"Next language to learn" is the kind of metric you'd use if you don't have real numbers to your advantage. TIOBE lists Scala at 0.03% mind share, and you'll get similar numbers if you look at other metrics (see my post above).
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?
I agree that Google should add more languages to android. And while Scala is a great language, it's very complex - so it won't benefit many of the less skilled users.
A better language would be something with the simplicity and power of python, but with good performance.Groovy could be one such 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.
Just because Scala has features that are tricky to get your head around if you're not familiar with functional programming, it doesn't mean it's complex to write software in. You can write Scala that's basically Java with less syntax if you want.
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.
It still doesnt change the fact that Scala, as a programming language, tries to incorporate too many concepts while still trying to be typesafe. This makes the language complex, and not an ideal candidate.
There's no substantiative argument in this comment.
> 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.
I'm a non expert in Scala and after a little learning it is extremely legible and provides many ways to clearify your syntax. If you're arguing that syntax should be obvious, I think that's a non starter in a technical argument. That's like believing that programming should be possible without programming.
"I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala."
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. ;)
> 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!
I think this is actually the crux of the issue. The language gives you enough rope to hang yourself with, and when people do hang themselves with it, those who look in from the outside throw the baby out with the bathwater.
I think that's definitely it. That old Dispatch periodic table has done a lot of damage to Scala's reputation IMO (even though it's no longer used by Dispatch).
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.
Scala doesn't really have an idiomatic style. There's no "The Scala Way" to do things. What you've encountered are functional programmers who really love terse programming, but terse programming is no more idiomatic in Scala than Java-style programming. You can even keep the semi-colons and explicit type declarations if you want.
Yeah, I understand that, but I think (and this is probably the Python programmer in me talking) that there's value in encouraging a preferred way of writing a language that facilitates people reading each other's code. I want there to be an idiomatic style, and ideally that style would be relatively legible.
This is Scala. It has dependent type support and loops with global state. Basically, there's no unified community. No one agrees on anything, except that everyone else's code sucks.
> So what? You don't need to know all the concepts to be proficient
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.
No, you don't. I've been working on Scala project with a team mostly comprised of people who never used Scala before and who came from different programming backgrounds. We can and do ignore huge portions of the Scala language and ecosystem (no Scalaz, no type system hackery). At the same time, we still reap huge benefits from the parts of Scala we do use. Immutability by default, high-level parallelism/concurrency constructs, monads, typeclasses, etc.
> It still doesnt change the fact that Scala, as a programming language, tries to incorporate too many concepts while still trying to be typesafe.
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.
The replies against you suggest solutions on an individual level, as in the problem being one of too many concepts for the individual. I suggest the problem is not too many concepts for the individual, but for a team.
Groovy's founder has said that he wouldn't have bothered creating it if he'd known about Scala at the time. In Scala you can write almost the same code as Groovy, word for word - but you don't have to give up compile-time type safety for it.
(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)
Groovy has supported compile-time safety since version 2.0 with the optional @CompileStatic annotation. It's one of the few languages where you can mix static and dynamic typing, even within the same class. With this annotation enabled, you get pretty close to pure Java performance but with 1/5 the lines of code in some case.
For something like Android, running Groovy with CompileStatic enabled by default would make a lot of sense.
> It's one of the few languages where you can mix static and dynamic typing
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.
Any optional and inconvenient feature in a programming language will never be used. It's why static typechecking in Python and Pypy and whatever will never take off.
Not true, the mix of functional and OO features make the language complex even without the libraries. Throw in implicits, higher kinds, pattern matching, a fairly good generic type system, support for all kinds of polymorphisms (subtyping, ad hoc, duck typing), etc... and you can see complexity emerge pretty quickly.
Implicits? Compared to Java, Scala is not a simple language. I'd say Scala's complexity is on the order of Haskell + Java syntax with additional glue on top of that.
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'd say this makes Scala slightly more complex than C++ and Ada. Java and Haskell are not in the same league when it comes to complexity (Java because it's simple, Haskell, because it's wickedly well designed so its complexity is completely tractable).
Considering that Visual Basic has monads, and lots of C# developers are regularly using closures, I think the response to "is FP accepted" is a resounding yes. Although .NET had to sort of smuggle those features in, under cover.
Why not Kotlin? It's more like a modernized Java. It's closer to what Android developers are used to and it already supports Android. It interoperates well with existing Java code in your Android app.
Also, it has excellent IDE support, since JetBrains is behind it.
It's less mature than Scala; it has a smaller developer base or library ecosystem, and it is missing many Scala features (higher-kinded types, implicits). Most of Kotlin's features are already present in Java 8; if you're going to go to the trouble of supporting two languages, it seems perverse to pick Java and Kotlin when they're so similar.
I'm not sure the author understands why Java is the language in the first place - there is an army of developers who knows how to use Java. Yeah, it might not be the best language ever, but neither is C++ and neither is Scala.
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
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.
When I say proven out, I don't mean in the sense of being widely used; I mean academically. In other words, I am trying to say that it's not a research problem, it's a problem of, say, engineering and marketing to bring it to reality. Cool language features are well established in academia (but tend not to go anywhere due to entrenchment and industry complacency – in that sense I would agree that they aren't 'proven').
Google would need to do this internally. Good luck convincing the 10,000 developers inside of Google stop using Java. Sure, they aren't all on Android, and there are plenty of people using Go, or Dart, or Python, but moving a company culture that large away from Java doesn't happen overnight.
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.
Indeed. Developers look to Google to set an example, but it seems that Google itself is looking to developers to set an example. Hence we have a circular pattern of language adoption :) But it doesn't have to be that way.
Please not scala! I prefer to have clojure for android. Scala is too complex, to ugly, and tries todo too much. Its also to heavy for android (it needs tons of libs to run).
It seems to be that what's really needed is better JVM language interoperability in Android, then you can choose your poison.
* 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).
Over the last few months I've been writing Scala full time, and have even written some (demo grade) Android apps in it. My opinion is: Android should not adopt Scala as one of its primary languages.
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.
The advantages of immutability are real. At some point an improvement has to be a change. Even if Google sticks with Java-only, I would very much hope they will offer a more immutability-friendly API in parallel with the existing one.
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.
Google should do something about their APIs, sure. But they should do something about their APIs before doing something about their language.
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.
> 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.
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.
If Scala makes developers more productive and code less buggy at all, it will only do so for some developers. Look at the investments required: APIs need rewriting, apps need rewriting for the new APIs, people need to be trained within Google, people need to be trained for it outside of the workplace, and other people will still look at Scala code and stay behind confused.
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.
> 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.
I think just fixing their god-damn bugs would be enough to make people happy.
> Scala can't even properly be a primary language in parallel to Java at the moment.
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.
> 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.
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++.
> You realize that Swift is not only resembles Scala syntax closely, but also adopts many of the same concepts?
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.
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.
In all fairness they also explained that they don't communicate about what they will or might do.
Although some core members of the Android team are indeed very outspoken on their opinion that a switch to another language would have a way too big cost/benefits ratio, it does not mean that it cannot happen at some point in the future.
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).
If I asked a restaurant if they would serve something besides bowls of gruel I would at least expect some sympathy like "we wish we could, but..." Instead they were actually mocking the idea and seem to have no clue how bad Java is.
Why do people think that Swift has a managed runtime with garbage collection? It has reference counting, it's compiled into native code. It has a small runtime lib. linked into the executable (but hey, even C executables have it).
The younger generations grew with VM based implementations, never learned the memory safe system programming languages that lost the market to C and C++ and lack compiler design understanding.
As such, any language they see announced as safer than C and C++ must be VM based.
If they're not even giving us Dart or Go for Android (their own languages), what is the probability they will give us official support for Scala? Yes, Scala runs on the JVM, and the former two don't. And yes, Go is not really designed as an end-user GUI application building language. But Dart has a nice VM of its own and is designed for client-side apps. I would like to see Dart on Android and the original author is definitely confused when he calls Dart and Go "niche" languages (as a way of dismissing them) and somehow doesn't feel the same way about Scala. Scala might be marginally more popular than Go/Dart but it's not an order of magnitude. In fact, according to the latest Tiobe index (a terrible metric in my opinion, but one indicator) Go is more popular than Scala by one place.
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.
The problem is that Scala generates very big jar files, which is why the only couple of Scala Android applications I've ever seen are toy apps. There is no doubt that any more sizeable project will blow up Dalvik's various restrictions like is already happening with Scala apps without ProGuard.
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).
That's three strawmen in a row, none of them coming remotely close to addressing the point I made above.
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.
Of course, but it's obvious they have zero desire to help support Scala on Android. First because they don't use Scala at all internally and second because even the languages that they created (Go, Dart) are not supported on Android. If Android ever officially supports a language other than Java, you can bet it will be one of these two.
By the way it seems that Dart is struggling to get any support at all within Google. Also, it's not statically typed and bringing it to the Android runtime might be much more effort. In short no, I wouldn't bet Go or Dart will be the solution, not unless these languages change a whole lot.
> 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).
The article reeks of ignorance. Swift doesn't really have GC (but ARC) - https://www.google.com/webhp?sourceid=chrome-instant&rlz=1C5.... It also takes an unnecessary dig at nodejs. Has the author ever written node.js production code? What bugs has the author found and filed?
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.
Adding more complexity to scala is its dependency on ASM for class file creation [1] and more refined performance options like tail-recursion [2] are implemented in a contrived fashion to make scala actually port to a non-standard JVM like dalvik .However if things were to change from ground-up like ARM actually made easy for functional programming.
These facts actually can make porting a performance application to scala quite a job!
There's also a commercial ($200) Common Lisp implementation that targets Android (and iOS): https://wukix.com/mocl
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.
You can use Scala for Android right now, as people are pointing out. However, it feels like a "second-class citizen" because the Android JVM has been optimized for enterprisey, Java-style coding with fewer, longer-lived objects than functional programming usually demands.
Theres a different between "supports writing your own code in that language" and "the platform APIs are in a language".
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.
This has a lot more to do with refactoring the build system than anything else. The more the build system adheres to the Java Gradle plugin, the easier it is to use Scala or other JVM compatible languages. There is an open ticket for it, and supposedly Gradle 2.0 will make this possible.
1. Most of the threads like this are going to turn into I like this language so let's rewrite Android in that.
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.
1) GC: VM issue. Has nothing to do with language.
2) API: Google's responsible for the Android API's but Scala's standard library is definitely better than Java's.
3) JNI performance is a VM issue, again, and JNI interface is Google's problem.
Yes, however there is a major caveat:
"Providing a Go equivalent to the Android platform is intractable."
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."
Knowing that Google and JetBrains have a good cooperation (Android Studio will replace Eclipse plugin as a preferred way to develop apps for Android), I kinda-sorta expected Kotlin to be backed from Google as an official Android language on the latest I/O.
"As phones are getting faster memory is not an issue anymore."
No, its not true. Memory is an issue. Android does not only run on premium devices but also economical devices.
So what? I think with the arrival of ART, it's also not an impossible task anymore, in terms of compatibility. They just need a separate team to rewrite all the existing API's in Go (and also catch-up with the new ones by the time they finish this project). How much would that take for a team of 20 developers? I imagine not that long.
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.
If we're talking about official support, then I'd rather Java 8 instead. And beefing up ART even more.