See Android Go
codingvelocity.com
codingvelocity.com
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.
That's my take on it anyways
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)
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 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.
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.
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.
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).
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.
You could also use C++, C#, JavaScript, Lua, Objective-C, Python, Ruby, and more. See http://www.mobilechameleon.com/
Some people just fall into using one language and want to use that language for everything. Why not let them?
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.
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
No, it's not. As it currently stands, concurrent shared-state programming is an unmitigated disaster for anything even slightly non-trivial.
Another is that there are no primitive types.
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.
Mostly it's the "because I can" reason. Why else would anyone program a computer?
Serious question, people.
[ are the downvotes because I mentioned apple is very controlling? ]
https://itunes.apple.com/us/app/ivy-big-number-calculator/id...
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.
Doesn't chrome and firefox finesse the target interface and rely on a portable C/C++ core?
?
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.
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.
If you have anything compute-intensive enough to affect battery life in an Android app, you really ought to use the NDK, and Go will probably be officially supported: https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_Ojjnj...
Or if you want Android/iOS portability, find a common API for SQLite and implement in C.
https://github.com/seclorum/ios-go-ipfs/blob/master/ipfsios/...
What's going on here?
[ * - See https://en.wikipedia.org/wiki/Bridging_(programming) ]
Does somebody know if there is a go -> emscripten/asm.js toolchain/example available?
I'm looking forward to writing all my android apps in Go!!!