Go and Android | Hacker News Reader

Go and Android

dennisforbes.ca

82 pointsstickhandle55 comments

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

Yes MIPS support will be needed for an official solution I guess (at least there seems to be only one ABI spec for MIPS Android, o32, MIPS32r1).

I really don't know how many MIPS Android devices there are out there.

This is nothing more than a pure hack as it is not supported by Google and does not allow distribution via Play Store.

The ticket for Go support is open since 2012, so clearly there isn't any interest from Android team to do so.

https://code.google.com/p/android/issues/detail?id=39482

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.

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

Yep, you are right, as I have seen too many of these workarounds.

And what is the benefit? Bending ourselves just not to touch Java?!

I rather be productive with the officially supported tools.

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.

> both written in C

JNI

Of course, there's an answer for anything. But I'd take Gos FFI over JNI any day of the week.

Plus, he also mentioned he has Go code he wanted to reuse.

There are Android apps in the Play Store that use Go extensively, e.g. Camlistore.

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.

[1] http://camlistore.org/

Someone on the Android team must be reading this, can someone make an official comment?

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.

Maintaining a Go wrapper for Android's Java APIs sounds non-trivial, and probably has security implications as well.

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.

Git-Annex does something similar: it's a binary written in Haskell, which runs a webserver and then launches the browser pointing to it.

> I'm not sure why Google hasn't adopted Go

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.

If you want to `range` over a non-rangeable thing, the idiomatic way to do this is to use an iterator approach:

  var e elem
  for nonrangeable.HasNext() {
    e = nonrangeable.Next()
    // do stuff with e
  }

Coincidentally, that's what the built-in io.Copy [0] does.

(I'm also very biased, but I think this approach fits better with the fact that Go is targeted towards stream processing)

[0] http://golang.org/src/pkg/io/io.go?s=11928:11988#L330

Objective-C doesn't have generics either. The id type is used just like interface{}

Also canonical is building QML support for golang, so they seem to think it's well suited to build apps for Ubuntu http://m.youtube.com/watch?v=HB-3o8Cysec

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.

Grandparent said:

Go was built with one purpose in mind; building web services.

App Engine is a web service. Whether you agree with that statement or not, it replies your question.

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.

What do generics or loop syntax sugar have to do with GUI development?

>What do generics or loop syntax sugar have to do with GUI development?

Nothing. Someone said something along the lines of "Go is only bad for mobile because it has bad GUI support." I disagreed.

Mobile development is more than just GUI development.

If the only thing I cared about when writing a mobile app was GUI support, I could write mobile apps in HyperCard.

Is there a HyperCard clone for the mobile?

Go 1.3 is going to target android/arm: http://talks.golang.org/2014/go1.3.slide#12. I'm not sure if this will lead to a full blown SDK for Android.

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.

Android runs on more than just arm -- anything supported by the platform needs to support MIPS and x86 as well.

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.

IMHO, it doesn't mean you can write for Android in go as much as you do in java.

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.

Hey Microsoft, if you want to blow my mind and have a good chuckle, implement Go into the Windows Phone NDK before Google does with Android's.

Why would Microsoft in their right mind do that? unless you port go to the CLR,it's not going to happen.

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.

Are you sure Go doesn't have this ability?

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.

Dart is what is coming to Android with ART eventually - not Go.

Dart has nothing to do with ART, AFAIK. ART is an installation-time compiler for Dalvik binaries (essentially an AOT compiler for Java).

did you see something about this somewhere? care to share or elaborate? (im really curious)

if thats is true, it means AOT compilation for Dart?

Would be nice if they started adding support for Go in Android 5.0, which won't be out until the end of the year at the very least.

Reply on news.ycombinator.com