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.
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