Every six months or so another way to run go code on android devices is published. Sometimes it's SDK wrappers, other times (like this) it's native executables.
The author's approach is interesting, but lacks MIPS support (though would extend successfully to x86 devices, as the author notes).
My almost equivalent attempt was to rebuild the Android NDK (native development kit) toolchain with --language=go added, and built all the GCC/GNU toolchain support for it for all targets. (Granted the rebuild-the-toolchain solution can be a bit hairy if you're not familiar with it.)
You didn't read his post to the end - you can include the Go binary into your normal Android app and then manually execute it. It certainly does allow distribution via Play Store and many apps currently available through the Play Store do similar things with Python and other languages.
Many apps also use this method as a way to get around GPL'd code by distributing the GPL executable as a separate runnable application inside the .apk (.zip) file which allows their app to be closed source while containing GPL code.
I wouldn't confuse productive with officially supported - sometimes an unofficially supported tool can be far more productive.
I agree completely with productive though. Anybody choosing a language for any reason but the quality of the output is just wasting their own time. Nobody really cares what language you used at the end of the day, only what you produce with it.
sometimes its just the fun. If I could write android apps in Go I would play with it, and perhaps I would get some ideas about what to build on mobile platforms.
It's not about avoiding Java, it's about not having to rewrite your already written Go code in Java. I've used both Tor and pjsip libraries (both written in C) this way.
Thanks for the mention of Camlistore[1]. Wasn't aware of the project -- it seems to mirror many of the ideas I've been mulling about concerning storage.
I'm not sure why Google hasn't adopted Go as another supported language to develop on Android. It seems naturally and would expand the usage of the language.
I assume the long-term plan is that PNaCl will be handling language-support issues and so directly adding Go language-support to Android isn't worthwhile since the work will be reproduced by PNaCl.
Or it's just the usual problem that the left hand doesn't know what the right hand is doing. Historically, Google hasn't been so hot at integrating their various projects together, their new round of consolidating crap into Google Plus and Hangouts is both recent and demonstrates that this isn't their field of expertise.
I'm always shocked that Google doesn't throw even more resources behind Android. Android is well-positioned to take on Windows itself... but instead they juggle it and their Chrome platform and keep Android restricted to the tablet/phone space.
That was my first thought as well... it would be pretty trivial for the app to run a local web/socket service and for your front-end app to interface with it. If the UI isn't too complex your UI could be a simple web frame pointing to the local webserver.
The same reason Dalvik is using Java, the pool of potential developpers. Java was definetly a smart choice, wether one likes the language or not. Furthermore android apps can be developped in C++ too.
IMHO, it's not really a good language for mobile development. It is great for the task it was designed for; web services and infrastructure. I can't think of any other area I would choose to use Go.
You are simply offering an opinion with providing any supporting evidence. Where does Go fall short as a language for mobile? Why would it not work well?
People use JavaScript to develop mobile apps, for example. The rapid compile times would be great for iterative development and the fast performance might even be better than Dalvik.
>Where does Go fall short as a language for mobile?
Go falls short as a language for mobile in the same ways it falls short as a language for most things. It's simply not a very well-designed language.
Let me give you a few examples:
Terrible support for generic programming. Read almost any production go code and you see many instances of the interface{} type. This is basically equivalent to up-casting to Object in java, or passing things around as null* in C++. In many cases, that's the best you can do. All the type-safety of Python with five times the verbosity.
Many features are built-in, non-extensible language directives. Take the `range` operator. `range` only supports built-in types like maps, slices, and chans. You want to range over a tree? Too bad. Want to range over a graph? Too bad. Want to range over a queue or a linked list? Hmm, well too bad, or maybe wrap the queue or LL with a chan, write a helper function, range over that, and watch your performance go to shit.
Go was built with one purpose in mind; building web services. It's good at that. But really, the only things Go has going for it are decent threading primitives and a solid standard library.
So the answer is this: Go is not a bad language, but it is certainly no better than existing languages for writing mobile applications. Go offers nothing that would make me, if I were a mobile app developer, want to switch from Java or Objective-C. In fact, it's missing a lot of things that I might consider important.
well if you need generics that badly, I think you could improvise with this github.com/leeview/godsl/. My feeling is that in time Go will become a more multipurpose language than it is today. Even Rob Pike said that he and other authors have a list on which add everything that they would like to change in Go and consider it for Go 2.0 or Go 3.0 which could be not backward compatible with Go1.* (this is similar to what D lang did, D2 is a nice improvement on the lessons learned from D1).
That's your opinion and it's valid, but Google obviously doesn't agree since they've created the language, use it internally and have added support for it in App Engine. So the question is, what makes Go unsuitable for Android but suitable for App Engine.
I'm not the original poster and I have no evidence to share, but I'll point out that Go executables are often quite large due to static linking. Client-side apps have to worry about code size.
if I understood correctly, that problem is already being addressed in 1.3 and the size of the files will decrease with the work on the new compiler/linker.
I initially agreed, but realize it's just because go hasn't been widely used in GUI development. With a proper SDK, there's nothing wrong with it in this role that I can think of. In full disclosure, I've not done Android development out of my distaste for Java, so I'd welcome it.
> but realize it's just because go hasn't been widely used in GUI development
There are a lot more reasons than that.
For one, Go has awful support for any kind of generic programming. The closest thing Go has to proper generic support is the interface{} type, which is awful. It's basically the same type safety as a 100% dynamically typed language (i.e. almost none), but with a much uglier syntax.
A related issue is that Go isn't very extensible. For example, Go's iteration features only work on builtin types. You can't iterate over trees, graphs, sets, or any other non-builtin type.
For me, the only good things that Go offers are decent threading primitives and good standard library support. Nothing else excels, and some things are downright bad.
Dont know why just because of a negative critique, people have downvoted you.. so im doing justice and doing a upvote
I might not agree with this comment, but at least his showing the reasons why he dont think Go is a good candidate for mobile development, and his opinion is technical backed
I think this should be in some HN etiquette somewhere.. dont know why people are so sensitive when a comment is not to say something nice about something..
It's an interesting phenomenon that occurs on HN. It's fairly easy to explain. Each HN user that sees this post has a chance to view and comment on the post depending on his interests. A Python developer would be likely to simply skip this post, while a Go developer would be highly likely to view this post as he has an interest in using his Go knowledge on more platforms. That means we have a highly skewed distribution of people upvoting and downvoting comments on any language specific article.
For example, if there are 10 Go developers for every 100 Python developers viewing HN, in a thread such as this one, there may be 9 Go developers for every 5 Python developers. This means that a large percentage of viewers of any critical Go posts in a Go thread are Go developers. They will downvote that critical post almost regardless of content.
This is not a knock on Go developers, merely standard tribalism. There is an identical effect in Haskell, Ruby, or even Perl discussions. There is probably no solution - if you value karma, I recommend not posting critical comments about a language in a post specific to that thread. You should rather save those comments for more general threads about programming theory, etc. If you don't care about karma (and you shouldn't), then please keep posting.
Just because someone frames an opinion in technical terms doesn't make it relevant to the discussion. There's a mismatch in the levels of abstraction, claiming that a lack generic programming is Go's downfall for mobile application development.
Some people clearly feel quite strongly that generics are a vital part of any language. But they don't really tie into the difficulties of mobile app programming, which are (i) resource contraints, much tighter and differently prioritised to desktop and server programs; and (ii) dealing with GUI libraries, which typically have massive numbers of functions, nests of callbacks, and are generally fiddly to program. Generics can be a help with various algorithms but it's far from clear that they help with mobile-specific issues.
Your parent poster is the typical person who shouts about generics in every Go thread. Like the people who spit bile every time Stephen Wolfram is mentioned in any context, it gets pretty tiresome.
Every language doesn't have something. A better response would have tied those ommisions into GUI development. A set in Go is a hash, queues are channels. You can range over both. I've never used custom tree iteration in Java to build an Android app and I've managed to do okay.
Don't be mislead... this is just running on Android, which has long been possible. You still can't write/distribute a purely Go application in say, the play store.
It does have support, but I've seen exactly one MIPS droid (a budget tablet called a 'Cruz' that had great battery life and terrible performance) and zero x86 androids (other than ones I put together for myself from android-x86.org).
So, I wouldn't say it needs to support these platforms. Just that not supporting them would be a glaring omission.
Using the NDK is already such a pain in the ass (we are using pjsip in some of our apps) that I couldn't imagine why I would want to switch from C to Go, which isn't even officially supported.
And you have to consider that soon everyone will switch to the Gradle build system, which adds amazing possibilities, but also adds a lot of complexity with build types and product flavors on top of the existing complexity with the NDK.
This is awesome, one of those posts that reminds me why I read HN so much.
I'm an Android developer (they exist!) and I'll definitely try this out in my next app, just for fun. Anyone have any ideas for something I could do with this that I can't do, or do easily anyway, with a regular Java Android app?
Is there a way to build your Go stuff as a real, embeddable library and then call into it from C (via the NDK)?
I think this would be a more natural way of doing it, and also be potentially more reusable on other platforms like iOS (which forbid launching processes).
I would be interested in writing a simple HTTP server for my app in Go, and be able to invoke it (start, stop, etc) through a simple C-API. Then I could write the rest of the GUI in the native platform language (Java for Android, Objective-C for iOS).
I don't believe this would be possible as Go requires a runtime environment and garbage collection. If you called into a Go library through a function, you would need to manually set up the runtime environment and garbage collection before hand (and manage it).
I think you'd be happier just using sockets to communicate with your Go process. I've done something similar before and it works well.
So many languages allow doing this. Lua and Tcl are famous for this, but many other languages/runtimes also can do this, Python, Ruby, Javascript, C#, Java. They have a formal C API you can call through and define some memory management policy you need to conform to to interact with the garbage collector. This is pretty common stuff, albeit that some languages are much harder to embed than others.
As I said, spawning processes and IPC isn't an option on all platforms.
You can call Go from C, but the process main entry point must still be Go's, since that's the only way to launch its runtime. So technically you could embed it, but then you wouldn't be able to do any allocations or running goroutines.
The author's approach is interesting, but lacks MIPS support (though would extend successfully to x86 devices, as the author notes).
My almost equivalent attempt was to rebuild the Android NDK (native development kit) toolchain with --language=go added, and built all the GCC/GNU toolchain support for it for all targets. (Granted the rebuild-the-toolchain solution can be a bit hairy if you're not familiar with it.)