7 ms·

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 do

by V-2 11y 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" : )

tosseraccount 11y 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 11y ago
  Yes, Ivy recently passed review. UI code is native, business logic is Go. https://itunes.apple.com/us/app/ivy-big-number-calculator/id1012116478?mt=8 https://itunes.apple.com/us/app/ivy-big-number-calculator/id...
  - Zypho 11y ago
    This is what I want to see more of, I get very worried about any tech claiming to overtake the UI layer of your application and make it cross platform. It never makes sense to do IMO. Logic and models though however, I can't wait!
    - threeseed 11y ago
      Couldn't agree more on this. And hopefully there are a enough examples now to show why it simply doesn't work. If you can't be bothered to fully embrace the design approach of the host platform e.g. Material Design then don't expect your users to be bothered to download your apps. Because most people appreciate that their apps look and feel like a true native app and not some cross platform version that was designed to put the developers first and the users second.
      - tosseraccount 11y ago
        People don't want to get locked into a proprietary interface. Doesn't chrome and firefox finesse the target interface and rely on a portable C/C++ core?
  - tosseraccount 11y ago
    How are they doing this? Is there some "transform" into C to use a subset of "objective c" going on?
    - rhodysurf 11y ago
      They are using this package https://godoc.org/golang.org/x/mobile/cmd/gobind https://godoc.org/golang.org/x/mobile/cmd/gobind to generate the libraries and bindings for objective c and java.
      - tosseraccount 11y ago
        "NOTE: iOS support is not ready yet. " [ https://godoc.org/golang.org/x/mobile/cmd/gomobile https://godoc.org/golang.org/x/mobile/cmd/gomobile ] ?
        rhodysurf 11y ago
        It works if you build from tip. Definitely not polished though.
    - glhaynes 11y ago
      Way back in like 2010 there was a clause added briefly to the iOS developer guidelines saying things had to be in Objective-C. There was an outcry and it disappeared not long afterward. Unfortunately, the idea that other languages can't be used persists. Shows how much damage a dumb political mistake can have, even if it's quickly walked back.
- tvon 11y 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).
codingvelocity 11y 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-2 11y 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)
  - codingvelocity 11y ago
    Thanks for the feedback, i'm pretty new to blogging and i've found the hardest part is giving the right context to my readers.
- threeseed 11y 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.
  - on_and_off 11y ago
    Not to mention that shitty devs can hide behind the Play Services... Google really need to add a way to shame devs that eat half your battery with play requests.
melling 11y 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 11y ago
  Is Kotlin's type system identical to Java's?
  - incepted 11y ago
    It's very similar, yes.
  - realharo 11y ago
    One difference is that Kotlin's types are non-nullable by default http://kotlinlang.org/docs/reference/null-safety.html http://kotlinlang.org/docs/reference/null-safety.html Another is that there are no primitive types.
dspillett 11y 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 11y ago
  But you can do the same thing with Java (or Scala or Kotlin).
  - troymc 11y ago
    Java, Scala, and Kotlin aren't the only options for "one language on the client and the server." You could also use C++, C#, JavaScript, Lua, Objective-C, Python, Ruby, and more. See http://www.mobilechameleon.com/ http://www.mobilechameleon.com/ Some people just fall into using one language and want to use that language for everything. Why not let them?
  - dspillett 11y ago
    Or any other language. I'm sure if someone wanted it enough a client-side implementations of PHP and Perl would turn up so you could use those languages in the browser. We might think it a bad idea, but for people who use those languages day-in-day-out elsewhere there is a possibility it might make some sort of sense. My point is that the "same language both sides" argument is relevant to any language, be the language Go, Javascript, or anything else, and be the client a native app on a mobile platform or running in a browser instance. If there are people who want to use Go client-side, why not let them? Just because it doesn't make sense to our workflows, doesn't mean it isn't the right tool for somebody else's job.
afsina 11y 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/mojo https://github.com/domokit/sky_engine https://github.com/domokit/sky_engine
- V-2 11y 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-android-with-dart/ 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_off 11y 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.
  - afsina 11y ago
    You experience is probably dated as they are changing things quite fast. They are making hundreds of commits each week. I think there are more demos but not yet ready ( https://github.com/domokit/sky_engine/tree/fb814cabf61c1bd3bd80ca197e4e8f00b6aad1ce/sky/sdk/example https://github.com/domokit/sky_engine/tree/fb814cabf61c1bd3b... ).
    - on_and_off 11y ago
      I am using the official demo app, which is be updated regularly. It is probably trailing several weeks behind the dev branch, but I don't think it is very far behind.
rough-sea 11y 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.
- pcwalton 11y 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?
  - rough-sea 11y ago
    No, the main go thread will receive events on a channel, all GUI calls can be wrapped channel writes, which get sent to the Android thread. Like how React Native is modeled.
    - pcwalton 11y ago
      In that case you're paying the cost of even more context switches. One to get into the UI thread and one to get out, in the case of a synchronous call. In a LockOSThread solution you don't need any context switches. You also save the memory cost of one goroutine (which is admittedly small).
incepted 11y 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 11y 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 11y ago
BIG FAT BINARIES!
tapirl 11y 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 11y 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 11y 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 11y 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 11y 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 https://github.com/greenrobot/EventBus/blob/master/HOWTO.md
- cartoonfoxes 11y 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.
cartoonfoxes 11y 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 11y 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.

by V-2 11y ago

tosseraccount 11y 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 11y ago
Yes, Ivy recently passed review. UI code is native, business logic is Go. https://itunes.apple.com/us/app/ivy-big-number-calculator/id1012116478?mt=8 https://itunes.apple.com/us/app/ivy-big-number-calculator/id...
- Zypho 11y ago
  This is what I want to see more of, I get very worried about any tech claiming to overtake the UI layer of your application and make it cross platform. It never makes sense to do IMO. Logic and models though however, I can't wait!
  - threeseed 11y ago
    Couldn't agree more on this. And hopefully there are a enough examples now to show why it simply doesn't work. If you can't be bothered to fully embrace the design approach of the host platform e.g. Material Design then don't expect your users to be bothered to download your apps. Because most people appreciate that their apps look and feel like a true native app and not some cross platform version that was designed to put the developers first and the users second.
    - tosseraccount 11y ago
      People don't want to get locked into a proprietary interface. Doesn't chrome and firefox finesse the target interface and rely on a portable C/C++ core?
- tosseraccount 11y ago
  How are they doing this? Is there some "transform" into C to use a subset of "objective c" going on?
  - rhodysurf 11y ago
    They are using this package https://godoc.org/golang.org/x/mobile/cmd/gobind https://godoc.org/golang.org/x/mobile/cmd/gobind to generate the libraries and bindings for objective c and java.
    - tosseraccount 11y ago
      "NOTE: iOS support is not ready yet. " [ https://godoc.org/golang.org/x/mobile/cmd/gomobile https://godoc.org/golang.org/x/mobile/cmd/gomobile ] ?
      - rhodysurf 11y ago
        It works if you build from tip. Definitely not polished though.
  - glhaynes 11y ago
    Way back in like 2010 there was a clause added briefly to the iOS developer guidelines saying things had to be in Objective-C. There was an outcry and it disappeared not long afterward. Unfortunately, the idea that other languages can't be used persists. Shows how much damage a dumb political mistake can have, even if it's quickly walked back.
tvon 11y 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).

codingvelocity 11y 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-2 11y 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)
- codingvelocity 11y ago
  Thanks for the feedback, i'm pretty new to blogging and i've found the hardest part is giving the right context to my readers.
threeseed 11y 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.
- on_and_off 11y ago
  Not to mention that shitty devs can hide behind the Play Services... Google really need to add a way to shame devs that eat half your battery with play requests.

melling 11y 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 11y ago
Is Kotlin's type system identical to Java's?
- incepted 11y ago
  It's very similar, yes.
- realharo 11y ago
  One difference is that Kotlin's types are non-nullable by default http://kotlinlang.org/docs/reference/null-safety.html http://kotlinlang.org/docs/reference/null-safety.html Another is that there are no primitive types.

dspillett 11y 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 11y ago
But you can do the same thing with Java (or Scala or Kotlin).
- troymc 11y ago
  Java, Scala, and Kotlin aren't the only options for "one language on the client and the server." You could also use C++, C#, JavaScript, Lua, Objective-C, Python, Ruby, and more. See http://www.mobilechameleon.com/ http://www.mobilechameleon.com/ Some people just fall into using one language and want to use that language for everything. Why not let them?
- dspillett 11y ago
  Or any other language. I'm sure if someone wanted it enough a client-side implementations of PHP and Perl would turn up so you could use those languages in the browser. We might think it a bad idea, but for people who use those languages day-in-day-out elsewhere there is a possibility it might make some sort of sense. My point is that the "same language both sides" argument is relevant to any language, be the language Go, Javascript, or anything else, and be the client a native app on a mobile platform or running in a browser instance. If there are people who want to use Go client-side, why not let them? Just because it doesn't make sense to our workflows, doesn't mean it isn't the right tool for somebody else's job.

afsina 11y 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/mojo https://github.com/domokit/sky_engine https://github.com/domokit/sky_engine

V-2 11y 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-android-with-dart/ 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_off 11y 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.
- afsina 11y ago
  You experience is probably dated as they are changing things quite fast. They are making hundreds of commits each week. I think there are more demos but not yet ready ( https://github.com/domokit/sky_engine/tree/fb814cabf61c1bd3bd80ca197e4e8f00b6aad1ce/sky/sdk/example https://github.com/domokit/sky_engine/tree/fb814cabf61c1bd3b... ).
  - on_and_off 11y ago
    I am using the official demo app, which is be updated regularly. It is probably trailing several weeks behind the dev branch, but I don't think it is very far behind.

rough-sea 11y 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.

pcwalton 11y 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?
- rough-sea 11y ago
  No, the main go thread will receive events on a channel, all GUI calls can be wrapped channel writes, which get sent to the Android thread. Like how React Native is modeled.
  - pcwalton 11y ago
    In that case you're paying the cost of even more context switches. One to get into the UI thread and one to get out, in the case of a synchronous call. In a LockOSThread solution you don't need any context switches. You also save the memory cost of one goroutine (which is admittedly small).

incepted 11y 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 11y 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 11y ago

BIG FAT BINARIES!

tapirl 11y 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 11y 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 11y 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 11y 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 11y 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 https://github.com/greenrobot/EventBus/blob/master/HOWTO.md

cartoonfoxes 11y 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.

cartoonfoxes 11y 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 11y 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.