Published: Aug 29 2010 / 01:01
So my guess will be with Google is displace Java once and for all and the 4 languages of choice for Google will be:
Go has a good bit of sensibility of Python about it. Python was one of the inspirational languages for Go's design. However, unlike Python, Go can be compiled and linked into a binary executable and delivered as such - instead of having to deliver an application as a conglomeration of source text script files. Plus it is statically type checked language. Because of it compiles and links so fast it is as nimble to work with as Python scripting. IOW, it is an entirely suitable replacement of Python, and then offers up additional programming concepts such as goroutines for addressing concurrency.
Go isn't really any more low-level than Objective C, which, of course, still retains full C language capabilities. 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 on Mac OS X - 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 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 using Go.
However, Go is currently statically linked into a monolithic executable. For a 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.
So beyond static linking, 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 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.
Your comments mirror much of my thought with Go - that Dalvik would not be the VM that it would run on. Your thoughts on the monolithic executable is interesting - and something I wasn't aware of, but that I will take note of as I start my study of Go.
Thanks for the comment. You aren't the first to mention that Python will become a key player. I haven't spent a lot of time with Python honestly, and I guess I need to change that. I have done a lot of C++ in my day, but I didn't really expect to see a huge resurgence of it for new projects. I'll have to give that a second thought
I am thankful for the new things I learned reading your post. I have been reading a lot on here and have picked up some great ideas.Thanks for the insight!
How is Oracle suiting Google over technologies in a virtual machine are going to affect Java or any Java developer in any way?
Sorry for the delay in commenting. I am trying to keep up with comments here as well as on my site and I was traveling today. Oracle has over the last 6 months taken various actions to show that they are going to really focus on monetizing their Sun assets. Which I can understand their desire to do this.
But this has put the future of software such as NetBeans and GlassFish a bit up in the air. In addition, I believe that much of the community was looking towards Google to foster the Java language itself - notice the number of ex-Sun people at Java - which has been a bit sticking point in the this lawsuit.
But I believe that at this point in time, Google will look towards a new future that is not under Ellison's control. I think 4 or my last 5 posts on http://www.translucent-development.com cover my thoughts on this.
> has put the future of software such as NetBeans and GlassFish a bit up in the air
Speaking on the GlassFish side... Narrowly speaking, the lawsuit should not impact GlassFish - see . Time will tell if there will be any collateral impacts.
My thoughts on Glassfish can be found here:
Check out the roadmap . Or attend our GlassFish Community Event and ask directly the Product Managers (and the rest of us) 
I will make sure to check that out. I assume that you work with GlassFish? I did watch the Oracle presentations online when Oracle did the online transitions, and I have followed the issue of GlassFish, but have felt that that the language that they have used to "describe" the future of some product lines that compete with existing Oracle products have been less then clear.
Yes, I'm in the GlassFish team.
I agree the original "strategy presentations" left a number of open questions around the role of GlassFish, but I believe we have clarified those since then.
Thanks for the links. I just spend some time on the roadmap link, and I see that it says that GlassFish 4 would remain Open Source as well.
Is there an indication on the length of time that the community can expect to see an open source glassfish appserver out there? The reason I ask is that I know some development teams that have built and deployed to GlassFish (and pay support contracts), but that are fearful of what the TCO will be in the coming years.
I know that there has been talks for some of these teams of if JBoss or Tomcat even would be a better solution where they can correctly budget for the future. Any thoughts or inputs on this? Thanks! David
The basic monetization model for GlassFish under Oracle is the same as that under Sun: We provide a fully tested, production-ready, GlassFish. The Oracle product is that extended with some (closed source) Add-Ons and then supported with patches and know-how.
If I understand your question correctly, you are asking for how long Oracle will keep this model. As the roadmap indicates, there are no plans to change this basic model. As the roadmap also says, all plans are subject to change, etc, etc.
On a personal level, and not talking for Oracle, the market dynamics are what they are; the GlassFish plan under Sun originated under that market and it has not changed that much since then.
Hope this helps
The problem with Go for Android is that there is no compatibility layer for Java > Go. Developing on Android often uses other Java libraries so I think dropping in Go doesn't solve the problem.
I guess I'm looking beyond Android, and moreso, the next king (or kings) or enterprise computing. Then again, that is also taking in my opinion that java currently sits in that chair....and I know more then a few intelligent people that would take me to bat on that statement.
Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.
Advertising - Terms of Service - Privacy - © 1997-2014, DZone, Inc.