See Android Go

http://www.codingvelocity.com/2015/07/23/go-mobile-intro.html

by codingvelocity • 11 years ago

112 63 11 years ago

codingvelocity.com

Sumaso• 11 years ago

Very exciting blog post!!!

I'm looking forward to writing all my android apps in Go!!!

tosseraccount7• 11 years ago

Why not write it in C and slap on the native cocoa/win/gtk/android front end and have something totally "portable" to mac/ios/android/windows/linux?

jaegerpicker• 11 years ago

Because go is significantly safer and more productive (of course this depends on the developer in question but on average) and using the ndk with c/c++ for serious development on android is absolutely one of the worst modern platform development experiences out there.

cartoonfoxes3• 11 years ago

using the ndk with c/c++ for serious development on android is absolutely one of the worst modern platform development experiences out there.

I have to second this. Serious attempts to use the NDK for application-layer work will turn your hair white. It's by far the most god-awful mobile/quasi-embedded tasks I've had professionally. In my experience it's second maybe only to porting C-decompiled FORTRAN between families of obsolete and badly documented DSP chips.

rhodysurf6• 11 years ago

How is go not portable to all of those platforms?

tosseraccount7• 11 years ago

No doubt it's potentially portable. Can I compile a GO only program and run on ios?

Zigurd2• 11 years ago

Because it would suck. Android is about app modularity and inter-app cooperation. It is about installable services with high and low-level APIs. It is about handling multiple screen geometries not just with conditional layouts, but also with code reusability in Fragment objects. Skin-deep UI "portability" results in a lowest-common-denominator experience.

rhodysurf6• 11 years ago

Why does nay of that restrict writing business logic in c or go, then just interfacing it in the Fragment or whatever?

V-23• 11 years ago

The question is, why would I want that?

With the availability of Kotlin, Groovy or (somewhat limited I believe, but still) Scala on Android, what advantages does Go offer?

I was under impression that it's more of a backend language, tailored to the needs of backend devs

I understand the crossplatform argument - write a platform-agnostic library in Go, and use it in your iOS and Android app etc. but it doesn't answer "why Go, of all languages".

It's an honest question, not a flamebait. Is there anything specific about Go that makes it well suited for mobile environment, or is it like a using a great shiny truck to deliver pizza "because you can" : )

tosseraccount7• 11 years ago

Apple is (was?) very tight about what they allow on ios. Do they allow go programs on iphone and ipad?

Serious question, people.

[ are the downvotes because I mentioned apple is very controlling? ]

akhilcacharya• 11 years ago

Yes, Ivy recently passed review. UI code is native, business logic is Go.

https://itunes.apple.com/us/app/ivy-big-number-calculator/id...

tvon• 11 years ago

iOS has a surprising number of realistic language choices, where by "realistic" I mean a savvy end-user would never know you didn't use Objective-C (so, PhoneGap & co are not counted).

codingvelocity3• 11 years ago

Because you can is largely why I wrote the post.

That being said, i think the nature of go routines and how go handles threading could be very important for mobile. We are all walking around with handsets that have multiple weak cores. If we can spread the general work over those cores our handset could possibly get back to a lower power mode faster.

That's my take on it anyways

V-23• 11 years ago

Thanks for clearing that up.

I fell this is rather important, and kind of missing from your blog entry, as that's the first question that pops to my head as a reader (or at least a reader who's a software dev)

threeseed2• 11 years ago

You mean like Grand Central Dispatch ? It's been available in iOS for a few years now and is very well integrated into the language.

Also battery life is largely pointless for an app developer to lose sleep over. The tiny power saving you make will always be eclipsed by screen brightness, cost of poor networks (the radio won't sleep) and apps like Facebook which happily sit in the background with their VOIP mode active.

Not to mention users will punish you far more if your UI is poor or features are missing rather than if it chews up battery (which they largely will never be able to measure). I don't know many ordinary users who check their battery usage deep down within the many Settings submenus.

pcwalton3• 11 years ago

We are all walking around with handsets that have multiple weak cores. If we can spread the general work over those cores our handset could possibly get back to a lower power mode faster.

Any advantages gained from this are going to be lost due to the lack of a highly optimizing compiler. Unless you have a lot of cores, my general experience is that you need sequential performance first and only then can you think about achieving speedups from going multicore. Compiler optimizations matter even more on ARM than on x86 due to shorter pipelines, smaller caches, super-expensive synchronization primitives, and so forth.

Of course, to be fair to Go, the primary alternative is Java (though the performance-critical parts of Android tend to be written in C++), which as implemented in Android doesn't do a whole lot of optimization either.

I think Go could be a great choice for application development, mind you. I just don't think that reaching for it to get multicore speedups will work at the moment compared to the alternatives.

melling• 11 years ago

You probably don't. Kotlin, for example, seems like a great language. No big deal. Why does anyone have to convince you? Carry on. Now, those of us that use Go would like to carry on too.

proveanegative• 11 years ago

Is Kotlin's type system identical to Java's?

dspillett2• 11 years ago

I was under impression that it's more of a backend language, tailored to the needs of backend devs

For one thing it could mean only coding in one language on both client and server side. If three is little friction between the language and the needs of client-side code then the drop in context switch need between the two could be worth it to some people.

Much like using Javascript server-side when most considered it a client-side only language (an opinion that is pretty much dying away now - the remaining people who don't like the idea of it server-side don't like it client side either).

Nutomic• 11 years ago

But you can do the same thing with Java (or Scala or Kotlin).

afsina2• 11 years ago

I think Android's formal future will be the guts of Chrome (Mojo) and Dart. Some heavy weight developers are frantically working on it.

https://github.com/domokit/mojo

https://github.com/domokit/sky_engine

V-23• 11 years ago

Dart on Android could be nice, I remember Mottier had a blog entry exploring this possibility - http://cyrilmottier.com/2014/06/12/shaping-the-future-of-and...

This being said, I wouldn't expect Google to make any moves towards supporting Dart on Android, or in Android Studio, for that matter.

I'm not sure if they see much future in this project, given that they decided against integrating Dart VM into Chrome.

on_and_off3• 11 years ago

There are some great ideas behind Sky, but right now the sample app does not even open anymore on my Nexus 5 and when it did, it just showed trivial content. Displaying one spinning square is not impressive, you need to display 1000 if you want to make an argument for Sky.

I don't think that allowing the app to update its code on the fly is a good idea though. You lose the PlayStore automatic app analysis and those 5 seconds delays before launching any screen are not acceptable.

Maybe that Sky is the future of Android, but it seems it is still very very far away.

rough-sea2• 11 years ago

I don't think it's necessarily tailored to backend development. Go does have cheap threads, which is helpful for programming servers that handle many connections - but that won't hinder you developing a GUI.

pcwalton3• 11 years ago

Doesn't it mean that you have to use LockOSThread() for your main thread in order to avoid messing up the Android event loop, negating the advantages of cheap threads and forcing you to eat context switches when calling into Java land?

incepted2• 11 years ago

Seconding this. Also, the absence of generics and real exceptions makes Go problematic for the kind of complex and optimized software that's needed on Android.

dragonwriter• 11 years ago

Also, the absence of generics and real exceptions makes Go problematic for the kind of complex and optimized software that's needed on Android.

Generics, perhaps, but I don't see how either the slight semantic differences between Go panics and the various forms of exceptions in other languages, or the fact that issuing panics across public interfaces is generally non-idiomatic in Go makes Go problematic for complex and optimized software.

Those two features might make learning the optimum way to learn Go more time consuming for people who are already deeply attached to patterns ingrained from long use of languages all drawn from a set which have a different error handling structure and idioms, but that's different from the language as such being problematic for the purpose.

dschulz• 11 years ago

BIG FAT BINARIES!

tapirl• 11 years ago

The reason is, the future.

Because Golang, and C#, and Python, and more, are more open than Java. Java doesn't support iOS and other devices officially. Oracle is even not happy to let Java support Android.

vcarl• 11 years ago

That Oracle wants to prevent Java from being used on certain platforms after how heavily Java was marketed as the "runs on everything forever!" language is absurd to me.

throwaway999666• 11 years ago

Why wouldn't you shoehorn a language who's ergonomics and limitations have been argued for by how it would fit for concurrent (web)server code in larger projects into application development? I mean, err...

0xdeadbeefbabe• 11 years ago

I'm growing weary of the "backend" moniker. Sounds like a urologist.

Mostly it's the "because I can" reason. Why else would anyone program a computer?

lnanek2• 11 years ago

Agreed. Go is a systems language not really designed or good for mobile development.

I think the only advantage anyone could claim is for concurrency, but that actually very easy in standard Android Java using built-in classes like Handler, Looper, and AsyncTask. Even if it wasn't there are lots of solutions that involve annotations or event buses that makes things even easier than Go, like: https://github.com/greenrobot/EventBus/blob/master/HOWTO.md

cartoonfoxes3• 11 years ago

but that actually very easy in standard Android Java using built-in classes like Handler, Looper, and AsyncTask.

No, it's not. As it currently stands, concurrent shared-state programming is an unmitigated disaster for anything even slightly non-trivial.

cartoonfoxes3• 11 years ago

I'm following this with great interest. The Android work I do is extremely specialized, with much of the complexity being on the device-side, so I'm not yet sure whether I can speculate about the impact on other mobile developers with lesser requirements. Having language-level support for message-based concurrency alone would be an absolute godsend. The current batch of alternatives are simply way to janky. Go language is Google-maintained, the importance of which independent developers may not be aware of. For enterprise/line-of-business work, having a credible alternative to Java and C/C++ is very significant.

vorg• 11 years ago

With the availability of Kotlin, Groovy or (somewhat limited I believe, but still) Scala on Android

Did you mean "With the availability of Kotlin, (somewhat limited, but still) Groovy or (also somewhat limited I believe) Scala on Android"? Groovy is used widely for scripting builds in Gradle-based AndroidStudio, but it's use replacing Java for writing actual apps for Android is very recent, still buggy, and not widely used. Don't confuse the two uses of Groovy in Android.

rhodysurf6• 11 years ago

I have been playing with the gomobile "bind" command to generate cross platform libraries for my Android and iOS app. Its quite easy to use, but the GC has been a pain in the ass on iOS. Its hard to track what the Go GC is doing and I am fighting with a bunch of EXC_BAD_ACCESS errors when calling operations on Go data structures. Still its a pretty fun experiment to have one backend for all the different native front ends.

therealmarv• 11 years ago

Would like to see some apps which use go as business logic. Nevertheless there is not just iOS and Android. It would be great to have also JS covered.

Does somebody know if there is a go -> emscripten/asm.js toolchain/example available?

sajal83• 11 years ago

Waiting for them to release the source for Ivy. I made PoC android app writing UI in Java... but curious to know how to do it purely in Go without knowing how to interact with OpenGL.

See Android Go

Related Stories