Hacker News Reader

Comment by V-2 | Hacker News Reader

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" : )

View on HN

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

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)

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.

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.

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.

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.

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

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.

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.

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/fb814cabf61c1bd3b... ).

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

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

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/

Some people just fall into using one language and want to use that language for everything. Why not let them?

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.

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.

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

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

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.

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

It's very similar, yes.

One difference is that Kotlin's types are non-nullable by default http://kotlinlang.org/docs/reference/null-safety.html

Another is that there are no primitive types.

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.

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?

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? ]

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

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

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.

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?

How are they doing this? Is there some "transform" into C to use a subset of "objective c" going on?

They are using this package https://godoc.org/golang.org/x/mobile/cmd/gobind to generate the libraries and bindings for objective c and java.

"NOTE: iOS support is not ready yet. " [ https://godoc.org/golang.org/x/mobile/cmd/gomobile ]

It works if you build from tip. Definitely not polished though.

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

BIG FAT BINARIES!

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.

Reply on news.ycombinator.com