Why Android should switch to Go(thomashunter.name)
thomashunter.name
Why Android should switch to Go
http://thomashunter.name/blog/why-android-should-switch-to-go/
11 comments
I would love to see Go being used instead of Java, however unlikely that may be (don't think the Android guys would be that thrilled to throw out all their work). This article, though, doesn't really make a good case for it. It just says, "Hey, Go is BSD licensed, and they call it a systems language! Look, here's Hello World!"
While i truly love Go as a language i think it might still not be mature enough to be used as a full fledged language for Android. The garbage collector is still not mature and could use some optimizations.
You also call Java a systems language. I'm not sure i agree in that view since you don't have direct access to the hardware it runs on. You're still running on JVM which does jit compilation of your code. Java is a high level language falling into the came category as the .NET languages and Python.
I would still very much see Go on android as a fully supported language. Go is beautiful.
You also call Java a systems language. I'm not sure i agree in that view since you don't have direct access to the hardware it runs on. You're still running on JVM which does jit compilation of your code. Java is a high level language falling into the came category as the .NET languages and Python.
I would still very much see Go on android as a fully supported language. Go is beautiful.
The garbage collector is still not mature and could use some optimizations.
For mobile, I'd use reference counting, with an incremental collector working on the cycles. (And encourage the pros to use weak references.)
For mobile, I'd use reference counting, with an incremental collector working on the cycles. (And encourage the pros to use weak references.)
I'm skeptical. Incremental cycle collection is quite hard, and you lose the benefits of cycle collection (only tracing suspected-dead objects) when you move to tracing garbage collection as a backup for reference counting.
For mobile I would just use an incremental garbage collector with heavy usage of stack allocation and interior objects. Or use a reference-counted system and disable the GC entirely (leaking cycles).
For mobile I would just use an incremental garbage collector with heavy usage of stack allocation and interior objects. Or use a reference-counted system and disable the GC entirely (leaking cycles).
Incremental cycle collection is quite hard
Incremental GC has been done. It wouldn't be super efficient, which is why one would encourage the pros to use weak references.
Incremental GC has been done. It wouldn't be super efficient, which is why one would encourage the pros to use weak references.
When Go came out in 2009, Android was only 2 years old. Go was easily not mature enough.
Another consideration is Android was fighting for market share from Apple. Forcing Go on developers would just create another barrier to switching.
Go's ARM compiler (5g) still needs quite a bit of work before it can be used on Android. Right now, even the canonical "Hello World" program fails to work on a lot of Android phones.
There is too much momentum behind Dalvik that it would be near suicide to discontinue support. However that doesn't mean Android can't support both Java and Go in the future, but there must be a compelling reason to switch.
Another consideration is Android was fighting for market share from Apple. Forcing Go on developers would just create another barrier to switching.
Go's ARM compiler (5g) still needs quite a bit of work before it can be used on Android. Right now, even the canonical "Hello World" program fails to work on a lot of Android phones.
There is too much momentum behind Dalvik that it would be near suicide to discontinue support. However that doesn't mean Android can't support both Java and Go in the future, but there must be a compelling reason to switch.
Since dalvik is a vm, how likely would a go->dalvik bytecode compiler be?
Brad Fitzpatrick, one of the core Go developers, used to work on Android.
There are regular discussions on the golang-nuts mailing list about Go on Android: https://groups.google.com/group/golang-nuts/search?q=android
I certainly hope for Go as a core Android language.
There are regular discussions on the golang-nuts mailing list about Go on Android: https://groups.google.com/group/golang-nuts/search?q=android
I certainly hope for Go as a core Android language.
Objective-C, despite not being popular outside Apple, isn't proprietary at all. Many of Apple's frameworks are but the language itself is open. GNUStep is a resource for that.
Yeah, I stopped reading at "Objective-C, which is about as proprietary as can be."
I will admit, it is no Visual Basic, but still:
http://stackoverflow.com/a/2583842/538646
Probably a much better idea with the gift of hindsight. However, Objective-C is more than 28 years old, and Go is just 3 years old at time of writing. The Go language has changed and continues to change a lot, and tying such a large platform to it before it is ready would make backwards-compatibility a huge concern for Go, and stifle its innovative growth.
Go has a low adoption rate compared to Java among developers. Go can be the best language in the world, but until there is enough developers using it, it will be a huge gamble by Google. Also this would cause a huge distraction and it would surly put them further behind IOS.
I would love to see this happen, but I think its more likely the dart vm will replace the java vm.
With some work, Go can already work with the NDK. The problem is that almost all the APIs are Java only. The only exceptions are things strictly necessary for writing games.
I thought this was a bit obvious.. whenever Go matures.
How much more does it need to mature? The Android VM is not very mature and it isn't nearly as performant as Sun's Hotspot compiler. I would never throw out the "Java" language but having Go as an option might be good for developers, with its near instantaneous compile times and concurrency model. It could be used instead of the NDK, for example.
I agree, there's too much invested in Dalvik as a Java environment for Google to throw that out, however the Oracle lawsuit works out. I wonder how feasible it would be to make Dalvik run Go the way it runs Java. If it runs reasonably well, that would be a great option.
Could they use NaCl as the native platform for developing Android apps?
Strictly NaCl is a VM, not an API or platform. What APIs there are are limited to a handful of system libraries used for in-memory work supporting a broader UI written in the browser.
So you could make your "platform" a HTML5 environment supporting NaCl, which is more or less what ChromeOS is. But that's not Android, and doesn't really have a migration path from the existing Dalvik frameworks.
So you could make your "platform" a HTML5 environment supporting NaCl, which is more or less what ChromeOS is. But that's not Android, and doesn't really have a migration path from the existing Dalvik frameworks.