Where is Google “Go”-ing?
IS IT TIME TO ‘GO’?
Today, Google introduced their new systems language called ‘Go’. Where does the name ‘Go’ come from? Well, lets put it this way; the documentation states that a great name for the debugger would be ‘Ogle’. I will let you put the pieces together. ‘Go’ is Google’s alternative to C or C++. The primary difference is that they have removed many of the language constructs, which either contributes to coding errors or common problems related to secure coding. In addition, they have added fundamental support for concurrent execution and communications, garbage collection, and even multiple return values. All of these features are interesting, and would be a joy to have in a major language; however, none of them are groundbreaking in nature.
LOOK BOTH WAYS BEFORE CROSSING
Everyone is looking in the wrong direction. Most of the literature and editorials that I have read so far all seem to focus on the fact that Google has introduced a new language to potentially compete or replace C/C++ or Java. They are trying to figure out why the world needs another language. Is ‘Go’ better than C++? Why can’t you just create new classes in C++? Should major new applications be written in ‘Go’? How does ‘Go’ compare with Java? They are all missing the point. Google did not create a new language just for the fun of it nor the technical challenge of it all. Furthermore, this is NOT a battle of the computer languages; this is a battle for the next major operating system: The Browser Based Operating System. The introduction of the ‘Go’ language is a key strategic move in this direction.
CAUTION – CURVES AHEAD
What does a language have to do with a browser!? Months ago, Google quietly introduced a powerful new feature into the Chrome browser called Native Client. This is essentially a sandbox, which can run untrusted x86 native code. This has major implications. This provides browsers like Chrome the ability to perform intense computational tasks that far exceed the speed and capabilities of Flash/Java/Javascript/or Silverlight. In a perfect world, a traditional ActiveX control would be cross platform, unable to harm your computer/browser, and executed in a secure runtime environment. This is exactly what the Native Client provides! However, standard compilers cannot create code that is compatible with the Native Client runtime environment. According to the paper ‘Native Client: A Sandbox for Portable, Untrusted x86 Native Code’ presented by Google at the 2009, IEEE Symposium on Security, there are seven key constraints that must be met in order for code to run in the sandboxed environment:
1) Once loaded into memory, the binary is not writable, enforced by OS-level protection mechanisms during execution. 2) The binary is statically linked at a start address of zero, with the first byte of text at 64K. 3) All indirect control transfers use a nacljump pseudo-instruction. 4) The binary is padded up to the nearest page with at least one hlt instruction (0xf4). 5) The binary contains no instructions or pseudo-instructions overlapping a 32-byte boundary. 6) All valid instruction addresses are reachable by a fall-through disassembly that starts at the load (base) address.
7) All direct control transfers target valid instructions.
Except for constraint #5, most compilers don’t meet the requirements to produce valid code for the Native client environment. Google has introduced experimental modifications to GCC and other tools to produce Native Client applications, but they are all based around forcing an existing coding methodology to meet a new more secure execution environment. This technique inevitably leads to many compromises, and create a disconnect between the language, the programmer, and the reality of the seven aforementioned constraints. The ‘Go’ language will provide a modern day, systems type language, which will create code from the ground up that meets the constraints listed above. In addition, programmers won’t feel like they have to compromise on functionality or capabilities when developing software, because Google has replaced all important ‘C’ language constructs, such as Pointer arithmetic, with secure and very usable alternatives such as Slices.
CAN ANDROIDS DRIVE?
Google’s mobile platform, ‘Android’, certainly wont be excluded from the master plan. Currently, the premier language for development on Android is Java. However, Java is considered a high-level language and always struggles to meet the performance capabilities of a real systems language such as C or C++. It is noted in the FAQ that ARM chip support is currently under development has already been tested on Android phones. In upcoming years, you will find that Go will be used to develop plug-ins for the already robust Android browser, and also as an alternative language for Android mobile application and driver development.
FULL SPEED AHEAD
There are many interesting features in the ‘Go’ language that will make it a very intriguing tool for general application development, such as garbage collection, fast compilation, and flexible typing. However, in the near term you can expect the ‘Go’ language to mature quickly and fully support the Native Client environment. Currently, this support is not complete, however, it is certainly a high-priority for Google. Looking ahead, I believe that this ‘Go’ language will be the premier language for the development of plug-ins for the Chrome browser. Ultimately, it will become the foundational language of choice as the Google OS fleshes out and becomes a reality.