What's inside Google's new Go app for iOS and Android | Hacker News Reader

What's inside Google's new Go app for iOS and Android

sourcedna.com

74 pointsKateLawson21 comments

Hi, I'm the author. SourceDNA has built a platform for crawling the app stores & indexing app code. We provide app review, helping developers improve their code and security by finding apps that have out-of-date SDKs or use platform APIs incorrectly.

As a fun exercise, we looked into Google’s recent moves with Go 1.5 pre-release, which can compile apps for iOS and Android. They just published their first app (a calculator) on the app stores and we looked inside to see if there was anything too surprising. The apps are mostly Go, with a thin platform-specific UI and event layer but this does raise some questions about Google’s long-term mobile strategy.

Previous discussion about the app, including comments by one of the developers:

https://news.ycombinator.com/item?id=9875886

Let me know here if you have other questions. Is Google going after the cross-platform tools market? Is this the future of the Android SDK? Or is it just a curiosity?

Where did you get the idea that Go's syntax is inspired by Python ? I don't think I ever saw that claim before.

Array slices, godoc/pydoc, syntax relevance (export names by TitleCasing them), lack of semi-colons, etc. There's even a guide about it.

https://golang-for-python-programmers.readthedocs.org/en/lat...

It's not so much that the syntax was derived from Python (because it's not) as that the language was clearly informed by the authors' experience working commercially with Python, Java, and C projects.

With syntax inspired by Python

If anything, the syntax is inspired by C, with Pascal-order type declarations (variable first, type thereafter).

I wrote my first Go program this weekend. The syntax felt like a cross between Python and C, notably doing away with parens in if statements and returning multiple values.

Yes, this is what I was trying to say.

There was a great talk on the subject of Go for iOS/Android apps by Hana Kim at last week's Gophercon: https://sourcegraph.com/blog/live/gophercon2015/123653512740

Thanks, looks great. BTW, the notes say no support for os/exec, but this library code is definitely present in both apps. It may not be usable though. :-)

I disagree that there should be libraries for GUI components. As soon as you try that, you end up compromising the UX with either non-native UI components, or lowest common denominator APIs that try to bridge iOS/Android. Write your models/controllers and other logic in Go, but keep your views native and use go's bind tool.

Sidenote: You can write OpenGL ES apps in Go (aka games). These typically don't use native UI controls so that's a great use case for go mobile.

How important is native UI to users? Is there any literature on the subject? I've always assumed it was important, but I keep seeing big name apps reinventing the UI and going the custom route.

Who are the big names you're referring to? Many of them highly customize the look of the controls (Spotify, AirBnb, MSFT) but they are still the native controls. The back stack, physics, etc are all native.

In addition to providing the look and feel that users expect, native UIs are the most practical way to achieve accessibility for people with disabilities, e.g. blind people using screen readers like VoiceOver (iOS) and TalkBack (Android). You can implement the platform accessibility APIs for a non-native UI, but it's a lot of work; just ask the relevant developers of Chrome and Firefox.

Addendum: If your app uses a web view, it can be accessible, as long as you use standard semantic HTML elements and/or add the appropriate ARIA attributes and focus behavior for custom widgets. But in this comment, I was comparing a native UI to something completely custom.

I've seen this argument repeated ad nauseum over the past 15-20 years. I think it depends on what you want.

Yes to some having consistent elements of UI make some users feel very happy about using your software. Most probably won't be able to articulate why, they'll just feel a bit happier.

I don't think there's an absolute in this discussion though. The web has proven that people value having access to more capability more highly than how well every aspect of that capability works. You could view the lack of integration as a weakness of the web, but for me it reads as flexibility/empowerment for the developer. It's possible to view developer empowerment as a negative, but in the case of the web it's enabled it to tackle some interesting use cases that you might miss if you stick to the rules too zealously.

BTW, I think it's possible to build crappy UI natively too. It's a mindset thing. The web isn't native on any platform yet there are some web apps with great UI. There are also some non-native client apps (like Chrome) that I think (admitting my bias in Chrome's case) do a pretty good job.

Yes, direct GL access with a thin app delegate is the most common way C++ game engines like Unreal Engine, Crytek, and Marmalade are packaged for iOS and Android. There's no reason you couldn't do that in Go too, except for the lack of other libraries like scripting, mesh, etc.

I'm not talking just a simple GUI abstraction wrapper, which has earned a deservedly bad reputation. The more full-fledged UI models have gotten much nicer, like in React Native or Xamarin.

I agree.

> Unless a third-party fills this vacuum, Golang on mobile will remain a curiosity.

No, it will be used for shared libraries, as intended.

Yes, that's a good point. Though I'm not sure what Go library would be worth the couple MB runtime overhead purely by itself. Ideas?

About 1MB in my experience. Worth if if your app has a ton of custom logic.

Cool! I'm the developer of AnGoIde (the Go IDE that runs right on your Android device) and actually one of the future features was an option to generate APKs for custom CLI Go apps on Android; e.g., with a bootstrap GUI that just executes a Go binary. One challenge is supporting both ARM (different versions) and the x86 (gaining popularity) architectures, so I'm interested to see how the official tools will accommodate that going forward.

Go recently ported the toolchain to being self-hosted, so hopefully they can keep code-generation up to date as well. There's nothing special about the current Go mobile runtime so it should work on Android x86 as well.

http://golang.org/s/go13compiler

You can't fool me - this is an attempt to bring back APL!

Rooting for this stuff to keep moving forward, because as a Python(2) user, my Python3 migration is going to be to Go. It's just the ecosystem I'm waiting to catch up before I take the big plunge and port my relevant apps.

Reply on news.ycombinator.com