Oracle stabs Java in the Heart

It's fair to say that Go has a different approach to OOP style of programming than, say, Java or C++ language.

Here's a Go FAQ link that sheds a bit of light on that (but is just scratching the surface of the topic of OOP in Go):

http://golang.org/doc/go_lang_faq.html#inheritance

A comment about polymorphism in Go via interfaces:

http://golang.org/doc/go_tutorial.html#tmp_268

And type subclassing in Go using type embedding:

http://golang.org/doc/effective_go.html#embedding

This section on Go interfaces is a good read:

http://golang.org/doc/effective_go.html#interfaces_and_types

BTW, it's rather strange to see the use of pejorative comments such as "Go is a joke" - that really is just indicative of not having much insight into what Go language is about or like at all. The creators of the language are exploring a different milieu for doing such things as OOP and concurrent programming - after we've had a couple of decades of experience doing such with C++ and Java.

Well, I spent the decade of the '90s mostly in C++ and then the '00 decade predominately with Java and some C# (and the last half of the '80s doing mostly C). So I've traversed the arc, so to speak.

As such, I've found Go language to be a refreshing experience that rekindles new excitement.

You do realize that you can use Python today for writing Dalvik apps using Jython don't you?

Go isn't really any more "low-level" than, say, Objective C, which, of course, still retains full C language capabilities (Objective C could fairly be said to be more "low-level" than Go).

Objective C has been an entirely successful language for native app development on Android platform's principle rival, Apple's iOS. Unlike Objective C, Go langauge intrinsically relies on garbage collected memory management (Objective C only optionally has garbage collected memory and that is only on Mac OS X - is not available for iOS devices).

The Go language package library has been developed on top of POSIX and though it has been ported to Windows, it is easiest to bring up on Unix and Linux. Android has Linux as its underlying OS.

For Android development, the Android APIs would need to be re-developed with Go packages wrapping and abstracting them. That would probably be the most substantial work in adapting Go for Android.

There is already and ARM native code compiler for Go so there would not be a need for porting Go to run on the Dalvik VM. Hence the entire matter of Dalvik patent infringement could be dodged by going with Go.

However, Go is currently statically linked into a monolithic executable. For small Android devices, it would be good to enhance Go with a runtime shared library feature comparable to what Adobe did for the Flex SDK libraries where they can be cached by the Flash Player. There would likewise need to be version management for caching such libraries. That way different editions of apps built with Go could have their particular version of the core Go runtime libraries suitably cached on the host device.

So beyond its current static linking approach, Go would need to be enhanced to support some manner of dynamic linking to make the above library management strategy possible.

Wrapping the Android APIs with Go packages and adding version managed runtime shared library support are the two primary issues that would need to be addressed when attempting to position Go as a new flagship programming language for the Android platform - such that it could viably replace the use of Java language in that role.