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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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).
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.
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?
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.
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.
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).
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?
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.
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.
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.
"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.
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."
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.
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.
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!
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.
147 comments
[ 3.8 ms ] story [ 213 ms ] threadA 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.
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.
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.
https://wukix.com/mocl
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.
https://github.com/krisc/events/blob/master/tutorial.md
* 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).
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.
http://zserge.com/blog/android-lambda.html
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).
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?
Also, it has excellent IDE support, since JetBrains is behind it.
http://kotlinlang.org/
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).
As such, any language they see announced as safer than C and C++ must be VM based.
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.
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...)
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.
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.
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...
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.