Imagining a world with Google Go

A couple of days ago, Google announced Go. Naming issues aside (apparently Go was the name of another programming language a few years back), I’ve been pondering the viability of yet another programming language. We already have a jillion of them. “Is Google making another one just because they are Google?”, I have asked myself…

The main points that they have emphasized for the new language, in no particular order:

It compiles fast
It has concurrency “built-in” (whatever that means.. I haven’t investigated how well they have implemented it.. )
It is currently achieving 70-80% of the speed of natively compiled code

And, probably several other things that I’ve missed. The Go compiler is released under the BSD license, and Google has released it for several platforms, I would guess (and more to follow, inevitably).

After looking through the first bits of the tutorials, it has the rough appearance of being a pretty normal programming language, with a bunch of the syntax mish-mashed up, to make life more interesting for those of us that have touched a text editor and compiler in the last decade. Instead of saying int name; you have to say things like var name int; etc. It’s similar to C, but has intrinsic strings, no while, and some other things. Google says that the lack of header files makes things easier (for their compiler, I’d reckon) and so on.

So, as I mentioned earlier, I’m asking myself, “Why?”. Ya, it compiles fast. That’s cool. Speeds up development a bit. Built in concurrency support is cool. But, geez.. Another language? Google had mentioned that it would work well as a server language. Doing stuff like web site server backends.. Things like that. Fine, so be it. But did we really need another language for this?

Google seemed to be really excited about the fast compiling. For me, that seemed… well.. a bit of a yawn. OK, to be sure. But extremely exciting?

Hopefully you can see at this point a fair amount of skepticism.

This morning I noticed an article that mentioned Chrome and Go Support in the headline. A lightbulb went off in my head, I put 2 and 2 together, and now I’m going go share it with you, if you care to read.

We all know that GOOG wants to rule the world, while Doing No Evil, of course. I think we have a perfect storm building here. A confluence of events that has been building for a few years now. And when you’ve got the resources that Google has, you can afford to do things and shove things into the mainstream that smaller companies just can’t do. Let’s look at a few events.

We start out with the lowly web-app Gmail. Gmail has the distinction of being pretty sophisticated, as web pages go. There’s a lot going on behind the scenes. Kilobytes upon kilobytes of special javascript and dhtml combine to give the user experience that we see today. It is responsive and interactive in ways that couldn’t have been imagined a few years ago.
A few years ago, something like Java would have been needed to accomplish what javascript and dhtml are doing now. Java never really caught on, though. Blame whatever you want, but it just didn’t happen.
In 2008 we got Chrome. and the world rejoiced. It was lean, and it was fast. It wasn’t really feature-rich, but most Google applications start out that way. It was really fast for Javascript, which gave things like Gmail a speed boost. It’s (ironic) lack of chrome gave it the appearance more of blank template where the webpage or application was the focus. The mere name (confusing to the average user, I’m guessing) indicated that Google wanted the browser to fade into the background of the user’s mind and experience. Yes, Chrome is needed, and Chrome is doing things, but you, Mr User, are supposed to concentrate on the webpage/webapp.
Some might even say that Chrome could be thought of as ‘the operating system’, as long as all you ever want to look at are regular websites or javascript/dhtml monstrosities like Gmail. Hmm…
A while after Chrome was released, we learned that Google was working on built in support for real 3d support in Chrome. “What the heck can that really be useful for?”, we asked ourselves. They had some cool tech demos of flying around an island. Yippee. yawn.
We get the chromeexperiments. Cool. Impressive. Terribly fun to watch the balls drop and hit the lines causing the musical notes, as an example. Pretty amazing that they can accomplish that in a browser… Should we still call it a browser? Ya, that’s what it is……….
In the meantime, Google sees and appreciates that Gmail needs some help. Particularly in the startup. It takes a long time to get all of that javascript loaded. And, I will admit.. this is a real problem. On my Mom’s computer via a slow dialup, I’ve set it to not use the javascript version, because it seldom actually gets everything downloaded and running before something messes up and she can’t look at her email at all. So Google takes steps to alleviate this problem. They reorganize their files to attempt to take advantage of various idiosyncrasies in browser caching. If they can get the browser to keep parts of the Gmail startup locally, they can speed up the user experience. They have a lab feature where you can see the most recent messages in a text form while the rest of Gmail is loading. The whole user experience needs help. They are aware of this. Just for grins, let’s say it takes a good 10 seconds to actually get Gmail loaded and running.
Chrome has something in it called NaCL. Native CLient. Well, they are working on it, anyway. It allows a way for code to be run as though it were native. They are working on the security for it. They can’t allow you to get something off the web that will destroy your hard drive or anything. So they have to limit what can be done via the Native CLient.

That’s where are, intrepid readers. Now, let’s look at where we are going.

Does NaCL sound like anything I’ve mentioned? Do salt and coffee go together? Ya, I don’t think so either. Some might say that salt is more generally useful than coffee (caffeine-hounds aside).

Let me paint a picture for you. Let’s look into Google’s crystal ball. As we’ve already established, they want to rule the world, or at least your computer, while Doing No Evil. OK. Let’s get down to brass tacks.

Android may or may not play a role. I don’t think that Google is thinking quite ambitiously enough right now to assume that Android will take over the desktop anytime soon. However, they are working to make Chrome into the operating system. It’s the ideal platform for them. They are putting all of the pieces into place. It’s network aware (it’s a web-browser, after all), so the distribution mechanism for new software is a non issue. They’re building in 3d support. You want speed? I think that is where Go comes in. Let’s use Gmail as an example.

In a year or two (maybe less; not more), Chrome is going to have Go support and there will be a version of Gmail written in Go. Your user experience (and some behind the scenes activity) will go like this.

You will go to the Gmail website in Chrome. Source code for a Gmail client will be downloaded to your computer. Go can compile 120,000 lines of source code in less than 10 seconds on a laptop. I don’t know how big a Gmail client will be, but let’s say 120,000 lines. These 120,000 lines of source code get downloaded and compiled. (meanwhile, Chrome (or Go?) caches the version that you’ve downloaded so it won’t have to redownload or compile the next time you open your email).

Gmail then pops up as a natively running application in the Chrome window/application. Google will have a complete API that lets the Gmail client running in Chrome talk to their servers. Bandwidth requirements will drop, users will get a native application, which will run much faster than javascript and dhtml, and everyone will be happy.

That’s Gmail. You have the latest version of Modern Warfare 3 that you want to run? Take the exact same model. Chrome has 3d support built in. You go to the modern warfare website, the code is downloaded, and starts running. It asks for credit card info, you pay your $50 to buy the game, and then you play.

All of this is happening now via custom solutions, but Google is going to tie everything together. Why does a game developer want to deal with payments, patch distribution, changing 3d (software) landscapes, etc etc? If Google can provide a platform (operating system) that has all of the…. ahem… chrome….. needed to allow you to concentrate on telling the story that you want to tell, why would a developer want to waste time on everything else?

For the user, it’s pretty slick, too. You always get the latest version of software. If developers conform to the Chrome APIs, your software runs on any platform that Chrome runs on (currently Windows, with betas on Mac and Linux).

Is this perfect? Well, no. Lots of people like to have control over software that they buy. The model I’ve described (where I think we are headed) is truly software as a service. The website can cut off access at any time. (Kinda like the various App stores that exist now for mobile phones and gaming consoles)

Wow.. I tire of typing. I might add more to this later. I realize it isn’t perfectly thought out, but I’d still like to know your thoughts. You think this is where we are headed?

Be Sociable, Share!

The Random Thoughts Review

Leave a Reply Cancel reply

Sponsored Links

Archived Entry