Go support for Android | Hacker News Reader

Go support for Android

docs.google.com

358 pointsmyko156 comments

So I've finally been learning to write Android Java... and honestly, as a C#/Python developer, I figured it would be easy to pick up. Holy crap, how do you people live like this?

Yeah, I'll be trying out Go for Android. Give me an excuse to learn Go. Still don't like the idea of going without generics and exceptions, but maybe it'll surprise me. I figure we're all just biding our time until Rust is ready.

Unfortunately they will not be mirroring the Android SDK in Go, but only the NDK bits. It's noted in the document that it would be too much of a bear to keep up with the official SDK, and an automated tool would generate crappy, non-idiomatic Go.

I think Dart or another JVM language are the only hope for getting away from Java on Android. Dart is maybe a longshot at this point though.

The problem with Android isn't Java though, it's the Android API being an inconsistent hacked together in a hurry trainwreck. Everything they've added since 3.x has been an enormous improvement, but they never shook off the baggage of the initial push to release.

Fair enough. Even some of the newer APIs feel slopped together to be honest. Android development does feel like a constant battle with framework bugs.

All android APIs tend to have a large number of methods, but there will be absurd omissions. Example, the WebView has no way to return its HTML contents. So it's difficult to implement your own caching mechanism. Or an even more absurd example, the android YouTube player has no .stop() -- it is simply inconceivable that a media player lacks a way to stop a video, but there it is.

Back when I was writing a client for a REST website, the default HTTP library lacked POST. The recommendation was that every app which wanted to POST should bundle the ~2MB apache HTTP library, which seemed a little painful given that other than that, our app was ~50KB :(

> Example, the WebView has no way to return its HTML contents. So it's difficult to implement your own caching mechanism.

That's a feature to me. Respect my Cache-Control headers!

Funny I had the exact opposite impression after using Java years ago. I felt like Android's API redeemed Java in my eyes a bit. I never liked Java much but the emulator, the debugger, a documented API, lots of example, developer blogs all made it very easy to get started and I create a rather complicated app pretty quickly.

Looking back I wouldn't mind developing on Android again but I wouldn't want to necessarily do anything with Java by itself.

Have to agree, I thoroughly despised Java until I started developing for Android, it suited the Application Framework and made the language fun, developing fully functional apps with ease and speed.

Tell me about it. I'm constantly using the autocomplete to look through all options to complete a method when it should be consistent with other similar things. For instance, you set OnClickListeners but you add TextChangeListeners. This is just a simple example, and yeah it's a small thing, but it's the damn mental baggage of not relying on my brain's quick search to find similar things and having to spend the extra time that really wears on you after hours of it.

The level of hackery even drips down to their own documentation and code examples. There is a line in an old example for a TabPager I believe that said "It relies on a trick." How is this acceptable API writing and role-modeling from Google?

Look at it like this: if you need an IDE to get code written, things have gone off the rails. Most Android developers would be absolutely useless without code completion ..

I think it's "riskier" for Google to stick with anything Java related at this point. Even if it takes 5 years to make the switch, I think they should do it. They don't know what Oracle is going to do in the future against them. The recent win for Oracle has already showed them that they made a mistake not starting supporting Go 2-3 years ago when Oracle first sued them. This could end up costing them soon, but it could also get a lot worse. I think they can't afford not moving off Java. Plus, look how much excitement Apple caused with Swift for developers. They could do the same with Go for Android.

Dartlang is more appealing for mainstream programmer than GO, already has an IDE with debugging intellisense etc. and already has Android backend (see Dartlang source code)

Golang gets intellisense with with gocode. Go has some debugging with gdb and awesome profiling with pprof. While there isn't an official IDE, there are plugins for eclipse and IntelliJ. Go's approach makes it easier to use your favorite editor to code.

They have already paid Oracle. That case is settled. How could it get worse?

No they haven't; the case is still ongoing, remanded to the district court.

Given Google's relationship with Jetbrains for Android Studio how about Kotlin. Cut out Java entirely: Kotlin -> ART.

Kotlin seems approachable and modern. Also compiles down to JS.

We build every Rust commit against Android already: http://buildbot.rust-lang.org/builders/auto-linux-64-x-andro...

I'm pretty sure that was contributed by Samsung.

Plus, Rust doesn't have exceptions any more than Go does.

Rust doesn't have exceptions, but its error handling is less ugly than go. Functions that can encounter errors return a `Result` by convention. If you then want to propagate errors, you can do so nicely with the try! macro, which converts a successful `Result` into its value, or returns the error of an unsuccessful `Result`. Thus the following go and rust are semantically the same:

    val, err := error_prone()
    if err != nil {
        return nil, err
    }
    
    let val = try!(error_prone());

Personally, I find that error handling isn't that bad in go. I think it's at least no worse than exceptions. Exceptions make it too easy, for me at least, to just mindlessly propagate the error. Sometimes that's the right thing to do, but in go it's a lot less repulsive to handle the error since to propagate the error you would need handling code anyway.

Rust strikes a nice balance. You have to explicitly handle every error, but if you go with the by far most common handling code, you get some nice sugar that makes it mostly painless.

I find that propagating the error is what I want to do at least 95% of the time.

Part of the problem with Java exceptions is too many people feel obliged to catch exceptions, when they should be propagated.

Ideally, the only catches would be in the top-level loops (request / response dispatch for server, event loop for GUI, arguments for command-line).

That's not been my experience, often it helps to add more context to errors as they propagate through the layers. Unless you control the entire stack of function calls top to bottom as part of your application, I think it's ogyrn bad form for one library to bubble up another library's errors directly. It's effectively leaking implementation details and it means the clients of your library may also have to import your dependencies to handle the errors.

The failure mode of a component is a function of how it's implemented. When a library couldn't connect to a server or couldn't open a file, you gain nothing by wrapping that exception, unless it's to indicate the semantic nature of the server or what the file is used for - and these things are normally obvious from the stack trace method names.

Wrapping exceptions as they bubble up is only helpful if the wrapped exception adds context that aids in diagnosing the issue. Otherwise it's just boilerplate that obfuscates and gives a certain type of developer warm fuzzies. "Exposing implementation" is a non-counterargument - the component failed because its implementation preconditions were violated, you need to address those implementation preconditions to fix the problem!

You don't need to import dependencies unless you intend to catch the specific originally thrown exceptions, and that's not normally what happens in the top loop; it normally logs, dumps or transmits the exception message and possibly its stack trace. These operations are normally only rely on the base exception type, so there's no need to catch a more specific exception.

Problem languages for this approach, though, are C++ (where the culture makes a single base class for exceptions awkward) and Java (where throws clauses, a deeply misguided feature, may force dependency imports unless you specify 'throws Exception' - or my preference, wrap in RuntimeException).

PS: I should add the other fundamental problem with the Java throws clause is that it uses static types to analyze dynamic data flow in a language with polymorphism, which makes it a usability disaster. When the code being invoked is indirectly accessed via polymorphic references, exception flow checking falls apart. There's a reason Google Guava's Function and Predicate interfaces don't throw. But that's enough of my bugbears.

Well said. While I dislike Microsoft, the guy they hired from Borland to design C# definitely got the "checked exceptions suck" thing right.

The "finally" clause is underused in most Java programs and the "catch" clause is overused.

> "Exposing implementation" is a non-counterargument - the component failed because its implementation preconditions were violated, you need to address those implementation preconditions to fix the problem!

I don't think this is necessarily true; assuming an XML parsing library that throws exceptions on malformed XML, you are more likely to have simply supplied generally invalid XML than to have hit an implementation-specific exception type.

So, the exception is only implementation-specific in the sense that it was created by an implementation of the class of software you wanted.

But really, in my mind the issue of not wrapping exceptions means all of your client code is now tied to the transitive library, which means the implementation can't be changed without breaking API compat.

Better libraries express their dependencies in a pluggable way, which makes them more testable as well as composable.

The top-level application is usually a composition of libraries.

So in practice, I'm sanguine about apparently transitive dependencies. I prefer when exceptions from one library's plugged-in dependency flow through unmolested, as I see the libraries as mostly a flat dependency of the larger application. If you pull in dependencies transitively without paying much attention to them, you're sowing seeds for trouble with versioning, security scope, risk of stale projects if they're open source, etc.

I think of this as a corollary of Spolsky's law of Leaky Abstractions. Passing through exceptions means not trying to fool anyone into thinking they can work with the high-level abstraction without understanding anything about what's going on underneath.

Ideally the standard library provides base classes that act as core categories for different kinds of exceptions - IO, programmer error, data format error, etc. - so that general code can be written after a fashion when necessary. But I think you're fooling yourself if you think that such general code can be written the majority of the time, much less all the time. What's underneath always leaks through, one way or another, and if you try to ignore the thing that's underneath, you'll end up with brittle inefficient code.

Where high-level wrapping exceptions are justified is where there is an obvious chokepoint in the design - where the interface between several layers is very narrow. But this typically is at the junction between a service and a client - e.g. a web front end and back end, or async job queuing service, etc. - something where there is a service loop and probably service-specific logging of original exceptions, anyway.

> Passing through exceptions means not trying to fool anyone into thinking they can work with the high-level abstraction without understanding anything about what's going on underneath.

Except this is not what happens in reality, very few people see an internal exception type and go investigate the details.

Sure it's shitty practice, but it seems orthogonal to whether the internal exception types are exposed.

I'm not saying people should just ignore what is underneath, I just think that as a library developer, you significantly constrain what you can do without breaking API compat by exposing internal exceptions.

You could take a hard line stance and say that it should be a breaking change and people should go and re-evaluate the library after the change, etc, and then rewrite their code to deal with new exceptions. But in reality it just means that library will no longer get updated, and will effectively become stale for no good reason.

Scala is also a good option. The g8 template for Android apps is at:

https://github.com/jberkel/android-app.g8

I thought about Scala, but the Scala plugin for Android Studio is rumored to be buggy and Scala doesn't integrate well with Gradle build system. At least I couldn't get it to work and I gave up after a while. If they (Google) wanted Scala to be supported on Android, they would make sure it isn't such a pain. And some documentation - all I could turn to for help is a handful of random blog entries etc.

This Libgdx sample worked better for me, although I had to remove a bunch of ios bits to get it to work on my non-mac.

https://github.com/ajhager/libgdx-sbt-project.g8

Thanks for the tip. Did you get it to work with Android Studio? (I guess guidelines for IntelliJ Idea would apply)

If you're writing C#, it's hard to believe you'd find Java challenging.

I'm reading into his comment that he dislikes the tedium of Java's verbosity e.g., getters, no var/auto, no LINQ, no delegates, etc.

That stuff plus the terrible state of datetimess and the lack of obvious operator overrides like being able to test string equality with ==.

My guess is that that's his point. Java is easy to pick up, but the Android API is such a hurriedly-hacked-together piece of nonsense that it hurts.

Case in point: To make a list on Android, you need to jump through hoops, assign stuff to a "Tag" property (a field intended for hacks and workarounds), typecast your ass of, or if you don't do all that your list will perform absolutely shitty. So, the easy flow is a crappy, slow, buggy list. The "best practice" (which is not the easy flow, because hey, why would we make good stuff easy) is a "View Holder Pattern" [0] that involves using intended-for-hacks framework features.

On top of that, to my feeling there's also a big difference in quality between the enterprisey Java ecosystem and the Android ecosystem. Android-o-world is full of not-entirely-good advice and bad examples. Jumping into Android reminded me of past PHP experience: lots of well-meaning, but ultimately not-very-experienced people set the tone. Enterprisey Java might have AbstractFactoryFactoryProviders, but at least they have no buggy/wrong/hacky/insane code with 300 stackoverflow upvotes.

[0] https://developer.android.com/training/improving-layouts/smo...

I dislike Android as much as the next guy, but you have to do some extra work to make UITableViews perform well in iOS as well.

> Case in point: To make a list on Android, you need to jump through hoops, assign stuff to a "Tag" property (a field intended for hacks and workarounds), typecast your ass of, or if you don't do all that your list will perform absolutely shitty. So, the easy flow is a crappy, slow, buggy list. The "best practice" (which is not the easy flow, because hey, why would we make good stuff easy) is a "View Holder Pattern" [0] that involves using intended-for-hacks framework features.

You don't have to do that. For a list with homogenous items you can use a regular ol' ListAdapter, implement getView sensibly (i.e. re-use views, which is very little work) and it will perform just fine. We tried this with a list of 2,000 items (each item had two TextViews and an ImageView) and it was completely fluid on a Samsung Galaxy Ace.

> Android-o-world is full of not-entirely-good advice and bad examples. Jumping into Android reminded me of past PHP experience

I could not agree with this more. I'd say somewhere around 2/3 of StackOverflow Android answers are downright wrong.

You very, very rarely have to use the Tag property to make a list. You either use Tag as a View-cache system (the View Holder Pattern, which is total overkill these days), or because your data object model is broke as hell (aka, you suck at object design).

Everyone else just uses CursorAdapter which is easy to use and ties in nicely with things like Loaders and ContentProviders.

Java's datetime API and (to some extent) collections were a cultural shock to me (coming from a .NET background) :)

That's why there are all these crutches like Joda, Guava etc.

Rust is almost/ready for Android and iOS, granted that the language itself is still in a state of flux:

https://github.com/rust-lang/rust/wiki/Doc-building-for-andr...

More recently:

https://mail.mozilla.org/pipermail/rust-dev/2014-June/010323...

https://github.com/rust-lang/rust/wiki/Doc-building-for-ios

You are still stuck using the GUI toolkits of the platforms in their native tongues. I think Qt and Mono (so C++ and C# respectively) are the only toolkits that support both of them with one code base.

JUCE also does.

http://www.juce.com/

Perhaps not so much a Serious UI Toolkit(TM), but anything that eventually compiles down to GL would work too. This is how play-clj does it: binding to libgdx, which eventually calls some OpenGL methods.

While I did jokingly say "Serious UI Toolkit", there's more than a few awesome applications on Android that have very, very simple UI widget requirements. Particularly games, which according to the article, they're focusing on.

Kivy does too.

http://kivy.org/

Rust is a browser development language. Maybe he doesn't want to bother with memory management. Besides, is there a modern IDE for Rust (automated refactoring etc.)?

> Maybe he doesn't want to bother with memory management.

Who is "he"? The poster michael was replying to said s/he was waiting for Rust to be viable.

>Rust is a browser development language.

That's a ridiculous assertion.

It sounds like Rust, right now, can build a library that you can use in an NDK app. Go, right now, can build a service or utility that you can use in any Android app.

http://goo.gl/mkCaJd

It isn't integrated, and as they note as one of the gaps, doesn't currently support CGO (meaning you can't compile C code or libraries in with your Go executable), but it has worked quite well for some time.

You could always try the Xamarin way. Basically the same APIs, but with nicer languages (C# or F# instead of Java).

> Holy crap, how do you people live like this?

The hole point is getting advantages. Lucky us that it's hard; others won't keep pace!

Yeah writing java for Android is a pretty awful experience. But it's not going away soon - this Go release will only have access to the things you can already do in C++ on Android. Namely, OpenGL, audio, and touch input. That's about it.

Anything GUI or system-related you have to do in Java. You won't be able to use Go to run other apps, enable wifi, receive GPS locations, communicate over bluetooth, etc. etc.

Qt is worth a look, but it's still not quite ready.

As a C# developer, have you looked at Xamarin? I have done several apps with it, shared code between iOS and Android. I highly recommend you give them a try.

Another .NET dev here in the same boat as OP. I really want to play with xamarin but the cost puts me off :(

Is this an official project supported by either the Go or Android teams, or is it just an independent developer planning to take on this challenge? Who's David Crashaw?

"Engineer at Google"

http://zentus.com/

All you have to do is search "David Crawshaw", the first result is a Linkedin profile for someone who works at Google and the third result is a GitHub user that is part of the Google and golang organizations.

I'm on the Go team. My work has been internal to Google up until now.

Nice to have you be less internal!

Apple releases a series of books with hundreds of pages and hours of video using Swift, and Google releases a one page Google Doc proposing to use Go. And then people wonder why Apple is able to attract so many developers to their platform...

Hint: it's not due to the documentation.

Apple had a 3 or 4 year lead time, Go was a project to make better servers.

As someone else already said, this should not be Go it should be Dart.

Go in this case is seen sort of an in-between C and Java. But Go is not really as fast as C as much as we want it to be. So I don't know. Maybe it will be useful for something already written in Go to be ported. But I would rather see Dart succeed as a higher level-than java development language (both on Android and on the Web).

Years back I hoped Python would do that (being Guido was at Google and all). But as he confessed there was a minor political struggle internally over it and Guido lost. Not too long after he left Google.

I used to think like you too.. but after Jobs/Apple launched the iPhone the trend for jitted languages, as popularized by Java in the nineties is going down..

Because of the phones and batteries, AOT languages are more valued and even ordinary jitted languages are getting a AOT compiler.. ART for Java and even .Net

So Dart would need to have a AOT compiler first to make it more appealing to mobile phones.. also i think a lot of apps would not like to be distributed in source code form..

So langs like Go now are on the rise.. its funny how technology trends change over the decades... not while ago it was all about dinamic languages..

It has always been about language features, abstraction power, and maximized interactivity. Exactly how one achieves these isn't the main point.

Its all about influential people in tech, managing popular platforms deciding what technology to use for their platforms..

Eg. Basic, Javascript, Objetive-C

As i dont think people actually conciously choose to write in those languages because of its features.. thats why we have so many people grumpy about those technologies..

Languages that we choose because of better features, pretty often loose in popularity and adoption..

Sometimes those languages have some heroic comunity efforts and a vibrant community that can make it stand.. but this is pretty rare.. Python, Ruby(because of Rails)

It has almost the same mechanics of the fashion industry.. Some influential people decide what we gonna wear on the next 5 years..

We can use our "hobby language" of choice, because its our own decision.. but in the end of the day.. we have to mantain and work in code on those languages missing the "features, abstraction power and maximized interactivity" we love so much

As i dont think people actually conciously choose to write in those languages because of its features

Incorrect, or at least badly lacking historical context and perspective.

Basic: interactive. (Primitive REPL.)

Javascript: it was there. If it wasn't there, everywhere but influential people just wrote about it then it would have languished. Also, it is interactive.

Objective-C: has a lot of very good OO which was heavily influenced by Smalltalk. It is precisely the OO excellence that it was known for and which engendered fierce love for it in certain circles.

Remember also that these languages have been around for a long time, on hardware far less powerful than what we have today or even had a decade ago. The youngest of these languages is Javascript by far, and it is almost 20 tears old! For their day, they were advanced with respect to the programming mainstream by at least one measure. (In the Apple II days, BASIC was there, and it was interactive, and that was enough.)

I'm not saying these were the best available. But there is more to it than just fashion and influence/hype. (Otherwise we'd all just be using Java in the browser and for app servers.)

Also: Ruby was a hobby language once upon a time.

I never understood why everyone whines about Go's speed. The language, although stable, has a lot of potential into becoming much faster and performant. In every new version you can find speed-ups into different parts of it. I really don't worry about performance in Go. The Go team are very conscious about it and i am glad the bulk of development has been focused on things under the hood rather than adding features.

Go is more of a community driven technology.. more in the unix way style, i think google endorse it, but unlike Swift, i think they dont have a marketing department, official budget and the like.. so i think the comparison is pretty unfair

> And then people wonder why Apple is able to attract so many developers to their platform...

There are quite a few more Android developers than iOS ones, not sure what point you are trying to make.

Go will probably have zero impact on Android but Java has certainly been instrumental to Android's success.

I have been dying to find an Android dev who has at least written a real app but I'm overflowing with iOS devs. Any advice where to find these guys?

May I ask where you are located?

Around here (Central Europe, Austria) it's the other way around. It's a little bit harder to find good Android jobs than iOS jobs.

Maybe because Java has always been one of the more popular languages here and the amount of Android devs is just higher than the number of iOS devs.

It's the same here in SE Asia. I suspect that's because most people don't have the money to buy a Mac for iOS development but already have a PC of some kind and often a cheaper Android phone. Also, most university graduates here already know Java so they can start writing apps without having to first learn an exotic new language.

In Germany it's a PITA to find good Android developers... Good iOS developers on every corner but even average Android developers are hard to find. We also overall experienced a much slower development workflow with Android.

Interesting, since at our teams we haven't found significantly slower dev times on Android in comparison to iOS. Usually Android devs lose time on compatibility issues, while iOS devs take more time with UI/UX design.

But I agree, finding a good Android developer here in central europe is rather hard. Also finding a good Android job is rather hard - payment offers are usually atrociously bad.

> There are quite a few more Android developers than iOS ones

Do you have a source for this? My observation is that it's much easier to hire iOS developers than Android developers.

Swift has been in development since 2010 in secret. This is the price you pay for open source, you get to see things in an immature state which evolve over time.

Agreed. And to add, Swift is designed and marketed as an osx and iOS language. Golang still mainly targets CLI tools or server programs. If you look at how Go progresses, some of the devs on the team seem to be able to choose the feature they will work on and move it forward. This seems to be the effort of one man getting this initially working. If it pans out, they may throw more resources at it.

And Go was started in 2007! http://golang.org/doc/faq#history

It's got nothing to do with open source. Instead it reflects the different approaches taken by Apple and Google.

Apple designs something new, tries hard to get it right the first time, and commits to it completely. Swift is the way to write for Apple's platforms, period. It's appropriate for a "social media application, all the way up to a high-performance 3D game." There's no doubt that Swift is meant to succeed Objective-C.

Google experiments more, sees what sticks. Go, Dart, Dalvik, v8, NaCl... You sure have lots of choices, but the relationships between these technologies is unclear, and has the character of uncoordinated teams working in isolation.

Go was also never made to be used in context of Android - even more it doesn't even have dynamic linking capability and was explicitly made to generate completely static binaries for server deployments. Which is not compatible (at least not without some serious hacking) with an OS which has full API written in Java an requires JNI interface and boxing of every interaction for every API call.

While Go is a feasible replacement for C/C++ for native parts of Android applications (which are just normal Linux .so libraries linked against bionic) it would be a terrible fit for main application language without a full rewrite of most of the operating system (note that ART is certainly NOT a magic bullet here!). Note here that native (NDK) code has practically NO access to Android OS APIs (only APIs available are bitmap manipulation, OpenGL, OpenAL and limited sensors access).

It's staggering just how many misconceptions and lack of understanding of Android structure is there in those "Go for Android" threads.

For us Android devs pretty much three points would improve the Android development experience:

1.) Add Java 8 language feature support to ART/Dalvik runtime. This would clean up code immensely, especially in so concurrency and callback heavy use-case as a mobile app is.

2.) Clean up Android APIs and fix broken implementations. Add modern block/callback based APIs to replace listener-heavy code. Perhaps look at RxJava design patterns for core Android APIs as well.

3.) Improve tooling. Not the code editors (IDEA/AS with Maven or Gradle are decent enough), but the profiling tools, hiearchy viewer, tracing tools and other tooling which wasn't touched in years and are SORELY needed for good app development. Figuring out why a certain animation stutters right now requires stitching together several partially working tools with poor documentation.

Note that NONE of those issues would be improved by adding Go as a language to interact with Android and would just cause additional issues on Go/Java boundaries.

I agree with your points. "Official", out of the box support for Scala or Groovy wouldn't hurt, either!

As for IDEs, personally I grew to prefer Android Studio to Visual Studio (well, no ReSharper), although I have much more working experience with the latter. Especially in terms of navigating around the project. VS native refactoring tools are very rudimentary, too, even in VS 2013 - not much seems to have changed in YEARS.

Are you proposing that Java 8 closure syntax is the solution to deeply nested callback code? Hopefully not---because that doesn't really follow IMO. A proper solution for concurrency is to use the Actor model or something similar.

It's a solution for tons of boilerplate code which appears when trying to do patterns. Compare for example Reactive Extensions (which are pretty popular in Android community for management of concurrency) and just how much more verbose is Java 6 code with it's piles of anonymous classes vs. lambdas of Java 8 or Scala. Even though IntelliJ IDEA can hide that boilerplate pretty well, it's still tons of needles code you have to pollute your codebase when you're implementing those modern patterns.

In short, what I'm saying is, that at the current state of Android, implementing Java 8 features would bring simillar benefits than switching to a whole other language without having to rewrite whole runtime and most of the operating system.

>Apple designs something new, tries hard to get it right the first time, and commits to it completely.

Oh really? That must be why they removed all of their USB and HDMI ports to replace them with Thunderbolt ports. Anyway, let me get back to writing my IOS apps in AppleScript and hosting my website on my Xserve. While I'm doing that I'll being sharing my music listening habits will all of my friends on Ping.

The point of that is that they hardly ever commit to things as 'completely' as you imply. They just have a conservative marketing strategy where they won't release anything until much later than most companies would.

>Oh really? That must be why they removed all of their USB and HDMI ports to replace them with Thunderbolt ports.

That doesn't even make sense. Thunderbolt and USB/HDMI cater to different needs. When they added thunderbolt they DID take out their Firewire ports. And when they added USB they did take out legacy mouse, keyboard etc ports.

>Anyway, let me get back to writing my IOS apps in AppleScript

Again, doesn't even make sense. Applescript is a legacy language they maintain. Designed pre-OS X. Not something they actively designed for iOS or anything.

>and hosting my website on my Xserve

They would, if enough people were interested. They weren't, so they killed the product. Same for ping.

True re Google's experiments. Given there's one guy in charge of Android and Chrome/OS developers could use a clearer direction. Preferably an alternative to Java (Kotlin?) which can also run on Chrome OS.

> This is the price you pay for open source, you get to see things in an immature state which evolve over time.

Quite the opposite.

Wouldn't there be more people to write books and to work on SDKs when a language is openly developed?

It's pretty obvious they've just now considered adding Go to Android, and have just begun working on it. I'd like to think it's in part because of my constant pestering on HN about Google supporting Go in Android.

You're comparing apples to automobiles. The documentation and video accompanying the Swift announcement was the official promotional materials and guides. The document linked here is a development proposal sent by a developer to the golang-dev mailing list outlining his intentions to work on a feature for the next release.

Go also has documentation. Also, Go has a spec. Swift doesn't. That's a pretty big deal, don't you think?

Android is fairly open. You can run whatever you want on that platform. If you want to use LuaJIT, no one can stop you.

Also, this isn't "Google". It's one guy working for Google. He's on the Go team. He wants to make Go a viable option for games on Android.

If you like Go, this is a good thing.

Swift has a spec. Just go to Apple developers documentation.

I can't find a language specification anywhere. Can you give me a link?

go language spec hit #1:

http://golang.org/ref/spec

dart language spec hit #1:

https://www.dartlang.org/docs/spec/

java language spec hit #1:

http://docs.oracle.com/javase/specs/

For Swift, I can only find guides and references.

At one click distance for any Mac developer:

https://developer.apple.com/library/prerelease/ios/documenta...

From the very first paragraph:

"The grammar described here is intended to help you understand the language in more detail, rather than to allow you to directly implement a parser or compiler."

A language specification is for people who want to implement a parser/compiler/VM/etc. It's something you need if you want to standardize it (e.g. TC39 [ECMAScript] and TC52 [Dart]).

A language specification is also generally clearly labeled as such.

http://en.wikipedia.org/wiki/Programming_language_specificat...

PHP, for example, doesn't have one.

Ah, so you mean a formal language spec, not an informal one.

Edit: I forgot to mention that both Go and Java lack ECMA and ISO specs.

Yes, a language specification is just a prerequisite for standardization. However, it's also useful for people who want to write their own implementation or tools. It also makes issue handling a bit smoother, because you can always check what the spec says if two bits of the ecosystem disagree with each other.

> Providing a Go equivalent to the Android platform is intractable.

It may be several step beyond what a small team could do in a short time, but not intractable.

Shooting from the hip, the job looks like this:

1. Add Go language and debugging support to the ART runtime environment

2. Port the standard Go packages, using a single-architecture backend modified to produce ART compatible binaries to bootstrap

3. Add equivalent support for RPCs (AIDL) and Renderscript

4. Build equivalent APIs for those in the android.__.__ packages that make sense in Go, possibly taking this an an opportunity to redesign some APIs

5. Create equivalents for the apache.__.__ and java.__.__ that don't have equivalents or alternatives in the Go packages

6. Splice in an intermediate representation and refactor the Go compilers to be ART pre-compilers, or take the easy way out and compile go to a possibly enhanced Dalvik bytecode

It may seem daunting that Dalvik and ART embody Java runtime support, and that the current (near-future, really) toolchain goes Java -> Java bytecode (and acquires a lot of Java-oriented tooling this way) -> Dalvik bytecode -> native code precompiled for ART. But I do not think it would bloat an Android runtime too much to add Go as a first class citizen. The build chain has become a little awkward anyway with Dalvik bytecode as an intermediate step that making a Go back-end that compiles for an ART-specific intermediate language might be cleaner.

How do I put an asterisk in a comment here?

Android apps are meant to be platform independent. A pure Java Android app will run fine on both ARM (various flavours) and x86. I vaguely remember a MIPS implementation too.

Without the intermediate step (bytecode), you are pushing the awkwardness to every individual developer.

I just finished editing in step 6 and saw your comment after I hit update.

Currently, ART uses Dalvik bytecode as a platform independent intermediate representation. I wonder if Dalvik bytecode is ideal for that purpose.

Either I am not understanding something, or perhaps you are not clear about the system side of Android.

AFAIK, ART doesn't "use" Dalvik. It is an ahead-of-time-compiling run-time for Dalvik. IOW, ART wouldn't exist without Dalvik.

It is an ahead-of-time-compiling run-time for Dalvik.

ART and Dalvik fill the same role, and are redundant with each other. They both take DEX (which I suppose you could call Dalvik bytecode, but now that it's runtime independent it should just be DEX bytecode) and ART ahead-of-time compiles it into native code, while Dalvik JIT compiles it into native code where possible.

That makes the difference sound greater than it really is. In reality ART is simply "rebuilding Dalvik from the ground up based upon everything that had been learned". It isn't 100% reliable right now because it's an incomplete runtime with some issues.

Thanks for clearing up the terminology! I guess we muddled up the discussion by referring to DEX bytecode as Dalvik bytecode, and sometimes just Dalvik.

ART replaces Dalvik as the runtime environment in Android. Both use the same application packaging format, which contains Dalvik bytecode. ART pre-compiles it.

Dalvik bytecode (DEX) was designed to efficiently interpreted. Eventually, Dalvik added a JIT compiler suitable for battery powered platforms. What ART stops short of is replacing Dalvik bytecode, perhaps with a more efficient intermediate representation for the purposes of pre-compiling.

Platform independence isn't really a big deal. Apple managed this just fine with fat binaries, and you could have an analogous system on Android without problems and a build chain that automatically cross-compiled (easy in golang). Developers wouldn't even have to notice. The size of binaries is often a small part of the total size of the app - resources tend to take up much more room.

The real problem would be porting all the current APIs. If Google actually decided to do this though it would be a good opportunity to clean up the current APIs and provide a new version free from legacy cruft. So it is doable, but a fair amount of work to provide UI bindings etc.

The obstacles are more political and monetary than technical.

Apple controls and chooses the hardware targets by itself.

Android is open and the potential number of hardware targets is limitless. It's not just about the size of the binaries; the app and the programmer should ideally be agnostic of the hardware. On an open-platform with closed-source applications, the least awkward way to do this is to push the native translation to the run-time.

In practice, is the number of hardware targets larger than two or three? I doubt it would be a problem for google to certify hardware targets.

But here's the kicker: The number of targets is a variable. Google would have to force developers to recompile for each new ISA. New ISAs keep getting added, many of them ARM ISAs that are not mutually compatible.

Intriguing. I'm not aware of much, if any, interest in Go in the games community, but there we are. C# seems to have finally taken off big time.

What would be cool/interesting is if you can write half decent audio processing code in Go for Android without the GC kicking in at the wrong moment.

They're 100% right about the broader API though.

I'm surprised C# is gaining this much traction in the games community despite the complete abandonment of both XNA and Managed DirectX by Microsoft.

C# lets you develop games that run on Windows, OsX, Linux, Android, iOS, Windows Phone, Xbox and PS, while sharing all non-UI and parts of the UI code.

I think this is 90% a result of Unity.

Let's hope Unity will support Rust, too, then...and I guess Go now as well, if Google says they want it for games.

They don't even support the latest version of C#.

Would they have to be ported to Mono to be used for Unity?

Likely not - C# seems here to stay on Unity3D, but speeding up execution through tools like IL2CPP seem most likely.

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...

Unity only supports managed code unless you have Unity Pro, and its not clear to me how well you can use other languages; I think the support may be more for middleware libraries and such.

It's the best modern language overall (if you count everything: IDE, APIs, language design, cross-platform capability, capital backing, reach, approachability).

Also XNA is reborn as MonoGame. Microsoft wants to decouple from it's APIs and tools by offloading to OSS and third party (Unity3d).

Good desktop integration alongside P/Invoke, meant many game studios started moving their game building tools from C++/Qt/MFC to C#/Windows Forms/WPF.

So this way C# got a foot on the door, long before XNA and Managed Direct X came into the picture.

Go is interesting for game servers. Channels and selects are the shiznit! Not there yet, but has potential. Rust has even more potential.

We've moved pieces of our game backend architecture from Python to Go, especially the bits that really benefit from high concurrency and possible parallelism. Moving the entire API is a monolithic task, but I imagine we'll eventually get there. But carving out the bits that need high speed, high concurrency (like sending 500 GCM notifications a second, for instance) really thrive.

Our client dev is all Unity, however, and I don't quite see Go entering our client dev cycle at all. And I'm a huge Go fan.

Go might be a good fit for game servers, but it seems like a completely uninteresting choice for game clients. I'd imagine game developers would either want to continue to work in C++ and leverage their existing skills and code bases or use a high level engine like Unity. The potential market for this seems quite small.

I'd really love to see Google throw some serious engineering muscle behind Rust, with the long-term goal of making it the default first-choice language for Android development. I'm not holding my breath for this though.

The design of Swift was somewhat hobbled by ObjC/Cocoa legacy requirements but it's still much better language for native client development than Java, IMO. Sooner or later Google is going to need a better story here.

Having written a bit of Rust, I'm not sure it's suited to being the default language for any platform, simply because it's really hard; it forces you to plan the lifetimes of your data pretty carefully. If you don't actually need all the guarantees and performance Rust gives, it's quite possibly a better idea to go with a managed language. Not that I wouldn't like to see it be a first-class option, just not the first one you point the masses at.

I'd be happy to be convinced otherwise by someone who knows more. :)

It is still way easier than using languages with manual memory management like C and Pascal derivatives.

Since you are not forced to think about lifetimes, then you get memory leaks, double frees and dangling pointers, usually leading to crashes in totally unrelated locations or worse, security exploits.

Um, right. I did suggest a managed language as an alternative.

Yeah right, but for me managed is a term coined by Microsoft as .NET was introduced.

Any language with automatic memory management, be it via dataflow analysis, RC or GC is managed.

As a game developer I would be intrested in this. I would love to have my client and server code in the same language so I would not have to write things twice.

Having said that, I'm not at all interested in writing an app that was Android only so I'll be sticking with javaScript for a while yet.

I've been following this and, for me, the real story here is .so support from go which they need to implement to allow this. Previously the go run time has expected to be the one running the main method. The changes to the runtime to support android will also hopefully allow go to be used for things like extending python or R.

Don't hold your breath for dynamic modules. Basically it's the whole binary into a .so file for loading in Dalvik. The whole Go program is in that .so file.

Look at go-android (already working for quite a while).

> is .so support from go which they need to implement to allow this

.so support on Android is pretty broken even with C/C++ code. For example, do you know the Unix versioned .so convention? Compile to foo.so.1.142, then create a soft link called foo.so -> foo.so.1.142? Android doesn't support this in general, even with C/C++ code (see [1] for discussion; my recent experience with this issue is that it hasn't since been resolved).

[1]: http://grokbase.com/t/gg/android-ndk/11ae9h0sm5/how-to-load-...

I haven't tried Go programming. I really like all these alternate programming languages/tools coming to all these platforms. Very cool. So many things to learn, so little time.

However, I like Ruby. In that department, RubyMotion the popular iOS/Mac alternate programming toolset is coming to Android. Seems the floodgates of "use your language of choice" are opening...

If you are interested in alternate languages and tool sets for your development I'd give this a look. http://www.rubymotion.com

I am excited for this, if only because it might finally give me a random excuse to learn how to write code in Go. Does someone have more context on what the timeline for 'go 1.4' is?

They seem to release an update every ~6 months, so probably around the end of this year.

In full disclosure, i'm a bit of a Go fanatic. But two things that led me to the language.

1 - The tour. Seriously, just go through tour.golang.org and...you know Go. From there it's just little tricks and best practices, many covered in 'effective go'

2 - It's a tiny language. That's a plus or minus depending on who you ask.

If you aren't new to programming in general, you can pick up the majority of Go in a day I think.

I agree with everything axaxs has said here! The Go Tour and also the Rob Pike / Sameer Ajmani talks ([Advanced] Concurrency Patterns in Go, Concurrency is not Parallelism) are all great resources.

Being planned and discussed right now.

https://groups.google.com/forum/m/#!topic/golang-dev/eqBihsj...

December 1st. 1.3 slipped by two weeks but 1.2 was on the money.

It continues to amaze me that as people lay more and more interesting ways to interact with android using the ndk, even from within google itself, the official word on the NDK remains; don't use this unless you really really have to.

If you know anything about Android then this is obvious - crossing from Dalvik to unmanaged code gives you huge performance penalties because you need to rebox and (in alot of cases) copy memory as arguments are passed. It also causes huge amounts of pain as you need to convert Java objects into something compatible with your language.

For most cases it's just not worth it.

There are some good reasons not to use the NDK (like the rich android UI, webview, etc); but performance isn't one of them.

The point I was making is that despite the downsides, even people from inside google are using it now. Makes the android teams 'pretend ndk does not exist' stance rather ironic.

It doesn't. Native code is by definition code compiled for a specific ISA, and Android is supposed to run on several ISAs, including ARMv7 and amd64. Native code is cancer on the ecosystem when you look at it from an ISA diversity perspective.

Native code runs on far more architectures than Dalvik, including (particularly) in the embedded world.

And the NDK is a rather neat solution to the compilation issue. Once you've set up the toolchain properly, different architectures are simply not an issue. There's no architecture that Android runs on that doesn't accommodate native code.

After all, don't forget that under a rather thin layer of Java, the native code "cancer" is what is driving Android.

Hogwash. If you are talking about SOURCE portability, Java runs in just as many places as C code, including in the embedded world.

If you are talking about BINARY portability (which is what everyone was actually talking about), then native code isn't portable for shit, whereas Dalvik code happily runs on multiple flavors of ARM, MIPS, and x86 with official or partially-official support.

Unless you are proposing that Android adopts a Goobuntu design of "compile everything from source", then the portability of native code source is utterly irrelevant. And if you are proposing that, you are hopelessly naive. Not to mention you must really, really hate having battery life if you want to spend over an hour compiling & installing, say, Firefox.

Hmm, that's a very strange assertion, I've never seen Android tem "pretend that NDK doesn't exist".

NDK is just a preconfigured GCC for cross-compilation anyway (with custom build script). Native C code compiled with NDK is used all over Android core and it's used regularly in apps to provide speed boosts. But it has practically no access to Android APIs (with exception of OpenGL/OpenAL some sensors and bitmap functions) so it's totally unsuited for development of a full app in C or C++. It's role is pretty much the same as C code in python libraries - to provide boosts for performance critical code.

Taking that into account, I really have no idea who acts like "NDK doesn't exist". It's widely used, it's just not suitable as a main way of developing an app.

I've recently written my first toy app for Android (first mobile app) and it was more challenging than I thought it would be. The API seems a little odd but like I said first app so I'll have to get used to it.

Go has been on my radar since forever but I haven't written anything in it. This sounds like a cool announcement. I think my next mobile experiment will involve Apache Cordova though but now I'm tempted to give Go a shot (game is fine with me)

In my experience with Android apps, I've almost never had to use the NDK. When I did have to use the NDK, it wasn't because I wanted to code in C/C++---it was because there were strong, open-source libraries written in C/C++ that I wanted to use in an app (Though, I have no experience making games on Android).

If you want to check out Go, then the Go Tour [1] and the various talks by Rob Pike [2] [3] / Sameer Ajmani [4] are great resources. The Go Tour stands on its own as an interest-building resource; the several programming exercises it has you do are fun and challenging.

[1]: http://tour.golang.org/#1 [2]: https://www.youtube.com/watch?v=f6kdp27TYZs [3]: http://blog.golang.org/concurrency-is-not-parallelism [4]: http://blog.golang.org/advanced-go-concurrency-patterns

Okay, this could be interesting. I'm especially interested in how good the performance will be compared to Dalvik.

So is this basically the NDK but using Go instead of C? I was hoping I could not use Java at all...

This is great news, good to see Google building a mobile + desktop interface with Go. Just like Apple did with Objective-C.

And yet with Go there is more use of it for CLI apps and web apps. Adding mobile to that equation just makes it even more complete.

Good job Google.

That's really good news. I have been waiting for it for do long! Maybe Go will prove not to be suitable for Android development but still the whole ecosystem around will only gain from such an opportunity regardless.

I myself have been wondering why this is not their original plan with Go.

On a side note, it's already possible to build Android binaries with CGO as long as you use the external linker. Just build for Linux + external linked from the NDK.

You don't even need the external linker. Just build a normal linux/arm binary with CGO_ENABLED=0.

What this proposal brings is access to the NDK APIs. You could run Go on Android since over 4 years now.

I think title should be "Better Go support for Android NDK" Now it seems like a linkbait. I clicked and felt so...

"it also makes it possible to use the same code to bind to languages like Objective C" Yeah, go for it. :-/

I expect Dart to make it to Android (officially) before Go.

Just as I had thought they would go (pun intended) about it - https://news.ycombinator.com/item?id=7845660

Interesting!

Reply on news.ycombinator.com