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" : )
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.
> 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.
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)
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.
I didn't know about Grand Central Dispatch, my experience with iOS is fairly limited.
I agree that UI is super important, but personally if i find an app is chewing up my battery it's getting removed regardless of its utility. I've also helped a handful of ordinary users diagnose why their battery life is poor. The result is commonly a poorly optimized/buggy app which they uninstall. A dead phone is a useless phone. My experience is primarily android so your mileage may vary on other platforms.
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.
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.
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.
> 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).
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.
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.
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.
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.
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
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.
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.
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?
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.
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).
> 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.
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!
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.
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.
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).
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...
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.
> 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.
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" : )