8 ms·
What's inside Google's new Go app for iOS and Android
- NateLawson 11y agoHi, 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 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?
- Sphax 11y agoWhere did you get the idea that Go's syntax is inspired by Python ? I don't think I ever saw that claim before.
- NateLawson 11y agoArray 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/latest/ 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.
- 0h139 11y agoCool! 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.
- NateLawson 11y agoGo 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 http://golang.org/s/go13compiler
- bgentry 11y agoThere 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 https://sourcegraph.com/blog/live/gophercon2015/123653512740
- NateLawson 11y agoThanks, 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. :-)
- scosman 11y agoI 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.
- miguelrochefort 11y agoHow 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.
- scosman 11y agoWho 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.
- mwcampbell 11y agoIn 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.
- bengoodger 11y agoI'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.
- danieldk 11y agoWith syntax inspired by Python ? If anything, the syntax is inspired by C, with Pascal-order type declarations (variable first, type thereafter).
- michaelwww 11y agoI 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.
- NateLawson 11y agoYes, this is what I was trying to say.
- mjcohen 11y agoYou can't fool me - this is an attempt to bring back APL!
- BuckRogers 11y agoRooting 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.