Blue Sky On Mars

Apple iPad: Open and Closed

Obviously, the iPad was introduced this past weekend and probably a million words or more about it have spilled out onto the net. Here’s just a few of those words.

Yehuda Katz takes the open side in “A GREAT Day for Open Technologies”. Actually, Yehuda takes both sides. Apple has created a closed platform while at the same time creating a very powerful platform for the Open Web. The trouble is that if you view the iPad as the future of computing, it is a scary thought as a geek to work on a platform that is so closed off. That’s more of Peter Kim’s take.

Personally, I agree with stevenf’s take that the iPad is the “new world” of computing, and it’s really a better world for most users. But, it’s only “new world 1.0″. It requires another computer. It can’t print. I believe that Apple is going to create a Time Capsule sort of device to which you can dock iPhones and iPads without needing a full computer, because an iPad is a full-enough computer for most people. For now, though, iPad is going to start making its way in the world as that “third device” that Steve Jobs referred to upon introducing it.

Mark Pilgrim and I apparently had similar tracks to learning computers (though mine was a TRS-80 Model III, not an Apple ][). He worries that future tinkerers will be left in the cold because of devices like iPads. There’s a huge difference between now and a couple decades ago. Computers were all for tinkerers then. Computers are for everyone now. I think there will remain ways for people to tinker.

iPad SDK: No Multitasking, New Shared Files

MacRumors has a quick rundown of the new iPad SDK. It has support for external displays (for Keynote, I’d imagine). No multitasking is supported. There’s a new shared filesystem, which is presumed to be the way to get iWork documents onto the tablet. There’s also said to be support for apps that support both iPad and iPhone, which should be interesting.

zeromq: Very Lightweight Messaging

Martin Sustrik and Martin Lucina have written an article about zeromq (“a new approach to messaging”), which looks to be about as minimal a messaging system as you can imagine. It’s got an API that’s patterned after BSD sockets. The comments that follow the article are quite interesting and useful as well. There’s a comparison of zeromq, AMQP and RestMS and the different kinds of things those are good at. RestMS actually sounds quite interesting to me. I’ll need to read a bit more about Zyre, which is a RestMS implementation.

ScriptCommunicator: Long Polling for Every Browser

Amir from Plurk has created a small (80 lines) module (ScriptCommunicator) for doing long polling, regardless of the browser. Even if real time isn’t right for everything (this is SlowNews after all), Comet is quite important and this little library deals with some of the tricky bits for one style of Comet.

(fab): A DSL for async coding with node.js

fab will likely remind people of Lisp, because of all of the parentheses. Look more closely, and you’ll notice that the parens are not nested… because this is proper JS, and fab is working through function call chaining. The goal of fab was to provide a nice way to define how URLs get handled in a node.js-powered web app. It’s a neat idea and the result is reasonably clean.

gccgo is Official

GCC 4.5 is slated to include Go. It will be interesting to see when Go-based projects actually start appearing, and when the first Go-based “killer app” arrives on the scene (think of what CouchDB and RabbitMQ have done for Erlang, for example).

75% of Linux Code is Written by Paid People

Over the years, I have seen a number of people characterize open source as written by “hobbyists”. That isn’t actually a derogatory thing to say, because people volunteering their time to a project that they believe in and love will likely do it well and with gusto. But, I’ve always thought that the view of hobbyist-driven open source is not the likely picture for large and successful open source projects. Jonathan Corbet analyzed Linux kernel contributions across 2009 and found that 75% of the code came from people who were being paid to write that code.

Creating a significant open source project can be at least a full time job. For something like Linux, it’s obviously many full time jobs.

toppcloud: Easy, Reliable Cloud Deployment

The prolific Ian Bicking has just spread word of toppcloud. He’s been mentioning it on twitter for a while, but now he gives the full story. If you have to deploy server side code (and don’t mind using Ubuntu on your VPS), check out toppcloud as a way to potentially make things easier.

Hot Code Reloading for node.js

Blaine Cook has a branch of node.js that can hot reload modules. This is obviously great in both development and production, when implemented well.

A zsh Prompt That Understands Hg, Git, Mac Batteries

Steve Losh has created a seriously tricked out zsh prompt.

CommonJS: The First Year

CommonJS turned a year old this past week, and I wrote a retrospective on that first year. Short form: JavaScript is growing fast!

Geek Conversation Killers

Philip Guo has an interesting article about awkwardness of “geeks” in conversation. I have definitely both witnessed this and caught myself doing some of these things. If you’re a geek like me, put a few brain cells onto the task of watching for these things during your next conversation. Calley Soukup has an interesting collection of observations about how sci-fi fans communicate, dating back to 1999.

Feedback for SlowNews #1

“very promising debut!!!” @uhop

“Hypocrite. The article was posted today. Let’s see if it’s still here 24 months from now in the same form.” lutusp on reddit. Ed: this is odd, everyone has to start with a thought sometime. I’m pretty sure that in two years I’m still going to think that real time flow of random news is a bad thing.

A year ago today, I posted “What Server Side JavaScript Needs”, inviting people to come and turn JavaScript into a competitive platform for applications on the server. Quite a few people answered the call. While the focus of the group has been on JavaScript in non-browser contexts, we’re ultimately shooting for as much of a standard that can cross between server, browser, GUI and command line applications as possible. That’s why we changed the name to CommonJS in the second half of the year. Ironically, most of my own personal use of CommonJS so far has been in the browser. I’ll come back to the personal perspective, though.

The Original Goals

As laid out in my original blog post, we were seeking to create:

• A module system,
• A cross-interpreter standard library,
• A few standard interfaces,
• A package system, and
• A package repository

Note that the idea here is that this group creates specs, which will have multiple implementations.

The goal is to have these things working across as many operating systems and interpreters as possible. There are three major operating systems (Windows, Mac, Linux) and four major interpreters (SpiderMonkey, Rhino, v8, JavaScriptCore). Plus there’s “the browser”, which is a unique environment unto itself. That’s a fair bit of surface area to cover.

Oddly, I think the one of those eight “platforms” with the poorest implementation support is Windows. Most of the CommonJS developers are using Macs or Linux machines, so I’m not sure how much time has really been spent on Windows. I would imagine that JavaScriptCore on Windows is probably the least supported combination.

The good news, however, is that there are projects using all of those JavaScript interpreters and platform compatibility issues will ultimately be ironed out.

CommonJS and the ECMAScript Standard

The CommonJS group is a grassroots effort, and not some formal standards body. In some ways, however, it works like a standards body in that the people working on the standard are also implementing the standard-in-progress and using it to build real applications.

We have no control over the ECMAScript language, which is managed by the TC39 working group. However, there are a few people involved in CommonJS who are part of TC39, and I have firsthand knowledge of others who are keeping an eye on how things are going with CommonJS.

The CommonJS standard-in-progress is designed to work on a subset of ECMAScript 5 that can be made to work on today’s ECMAScript 3 interpreters. ECMAScript 3 is the standard that is running in all of the browsers. In other words, in a CommonJS application you can count on Array.prototype.forEach to be implemented. Obviously, applications can do whatever they want (array destructuring? knock yourself out, but your app will only work on SpiderMonkey and Rhino).

One certainty about CommonJS is that inventing new language syntax is out of scope.

The Module System

The CommonJS group has been remarkably good at avoiding bikeshedding. While there is discussion about names of things, there isn’t heated discussion about it. People are far more interested in issues of functionality and ease-of-use. This is a very good thing, and it allowed us to get modules out of the way early on.

Of course, the lack of bikeshedding doesn’t mean that everyone agrees on things. The CommonJS module system has its controversial aspects, but I think it does well given the constraints:

1. must work with ES3 syntax (destructuring could actually be useful, but we’re not going to do it)
2. modules should have self-contained namespaces and be explicit about data the want to export
3. it should be possible to make modules tamper-proof, though this is not a requirement
4. using a module should be competitive with using modules in languages like Python and Ruby

TC39 had considered adding modules to ECMAScript 4 and there are module proposals on the table for ECMAScript Harmony that would add some syntax to JavaScript that would look similar to CommonJS modules. Here’s a short module to give you an idea of what CommonJS modules look like:

var sillymath = require("extramath/silly");

exports.addTwo = function(num) {
    return sillymath.add(num, 2);
};

Personally, I find this to be reasonably concise with a nice level of explicitness. Some syntax sugar would be good, and I hope we get that in ES-Harmony. But, this syntax works fine today.

Of course, this syntax is not without controversy. The biggest controversy has been that require() is synchronous – the “extramath/silly” module has to be available as the module above is loaded. However, there are a couple of reasonable ways to deal with this problem and I am happily working with CommonJS modules in the browser which is the environment that is least tolerant to synchronous loading.

Controversy or not, this basic module system was ratified last winter and has been implemented on all target environments of CommonJS.

Discussion is ongoing for a tie-in to the module standard: the module transport standard. Without additional help from the browser or some additional scaffolding running in the page, the module syntax above doesn’t work via a <script> tag. By standardizing what that scaffolding would look like, it is possible for a variety of build tools, servers and client side libraries to come into existence to provide many options for loading modules in the browser. There have already been several implementations of CommonJS module loading in the browser, but a standard will make it much easier to mix-and-match client and server.

The Standard Library

I had hoped we’d get farther on the standard library than we have, but it can indeed be a long process. system and unit testing are the only ones that have been ratified at this point. We have come a long way on file access.

“What!?!?”, I hear you say, “there’s no standard for accessing files yet?” That’s right. And there are a couple of reasons that it’s been challenging to get there.

Consider that JavaScript does not even have a standard object to deal with binary data. That is a basic prerequisite to working with files. JavaScript strings are not the same as a binary data container. So, there’s binary data to handle, streams to figure out and then file functionality built on top of that. There’s also the consideration of whether file access is synchronous or asynchronous. We’ve made tons of headway on this, and there are certainly implementations of some of the specs. It’s just a matter of finishing them.

I’m hoping to see promises become a part of the standard, because some form of that interface is very convenient to use for asynchronous operations.

Standard Interfaces

We do have a very useful interface with implementations and people actively using it: the JavaScript Gateway Interface (JSGI). That spec has not yet been ratified, but it is getting closer and there are apps being built against it today.

Database access has not yet been standardized. It will be interesting to see if we can come up with a good interface that can usefully target SQL and NoSQL databases alike.

Package System

We have a recently ratified spec for packages of CommonJS code. I hope this will bring about a collection of good package managers with different focuses and targeting different environments. There have already been a couple of attempts to create package management systems, and the most fleshed out one that I’ve seen is Tusk, which is bundled with Narwhal. Once a few more specs are ratified, Tusk should be able to run on other CommonJS implementations.

Package Repository

Tusk is using GitHub as a package repository, and that is working okay for the time being. A couple weeks back, we got word that the jQuery plugin repository is going to provide a CommonJS package.json file for the ~5000 plugins in their database. This is exciting, because this infrastructure could prove to be very useful to us going forward.

JavaScript: Bubbling Up

2009 was a terrific year for JavaScript. In the browser, we’ve obviously seen tons of growth in increasingly sophisticated applications. I think the interest is steadily building to use JavaScript more and more outside of the browser. The two JSConf conferences (in Washington DC and Berlin) were great successes by all accounts I’ve seen. PhoneGap, Titanium and Palm’s WebOS have created ways for people to use web tech to create installable apps for mobile phones. node.js has been a huge driver for people to check out building scalable, asynchronous JavaScript apps on the server. And, of course, CommonJS is finding its way into more and more applications.

My Personal View

I had hoped to personally have more time to devote to CommonJS in 2009, but I am delighted at how a great collection of people have stepped in and carried the specifications and implementations forward through a lot of hard work and force of will. More than 5,100 messages have gone across the mailing list, and more than 10% of those have been from Kris Kowal. Kris has done a ton of work in ironing out many of the specs and deserves a good deal of credit for where CommonJS is today. He and Tom Robinson even stood in for me when I had to cancel my trip to JSConf.eu (thanks, guys!).

Taking a look at the top posters on the googlegroup, you can see how many people have put so much into CommonJS. More than 10 people have contributed more than 100 messages a piece and, for many of those people, there was a lot of time spent in the email discussions, IRC chats, spec writing and implementation of those specs. Plus, as early adopters, they have the joy of tweaking things as the specs have changed over time. Thanks to all of you for the dedication and the will to get it done.

Bespin’s client side JavaScript code is all CommonJS modules now, partly thanks to the efforts of Charles Jolley to migrate the SproutCore framework to CommonJS and creating the Tiki module loader. From that standpoint, I’m already using more CommonJS now than I did in 2009. I’m also hoping that 2010 will bring a Bespin server “reboot”, where we start migrating server functionality to CommonJS.

On the whole, I think that 2009 was a great year for JavaScript and CommonJS and I think 2010 is going to be even bigger. I hope to meet more enthusiastic JavaScript hackers at JSConf.us in April!

Comments?

You can direct them to the thread on the CommonJS googlegroup or email to editor@blueskyonmars.com.

SlowNews on BSOM: An Experiment

This is my first SlowNews issue. Read What is SlowNews?, if you’re curious about it.

Sikuli: Picture-Driven Scripting

Sikuli

The Sikuli project out of MIT has to be seen to really get a feel for it. The short of it is that it’s a scripting language for controlling applications that works by taking screenshots of the various controls that need to be clicked on or otherwise manipulated. Sikuli uses computer vision techniques to find a matching part of the screen at that point in the script. This is seriously cool.

Firefox 3.6: Speed, Personas and Video Controversy

Disclosure: I work for Mozilla. My opinions are my own.

Firefox 3.6 was released last week, representing a lot of work from a whole lot of people. JavaScript performance is faster still than the already fast 3.5 and there have been a number of other areas of the UI that tightened up, performance-wise. Personas made it into the main product (before they were available only as an add-on).

Unrelated to the 3.6 launch, there was some controversy as YouTube and Vimeo both announced support for HTML5’s video tag. Firefox supports the <video> tag, but not the H.264 codec used by both YouTube and Vimeo. There are some very good reasons for this, which Mozilla’s Mike Shaver went into detail on. Chris Blizzard went into even more detail, and provided an interesting historical comparison with gif. Those are worth reading if you produce any videos for consumption on the net, because the issue extends not just to browser manufacturers and sites like YouTube. Even people producing videos encoded with h.264 may find themselves with a bill to pay come 2011.

Pintura: CommonJS/JSGI Server-Side JS Framework

Kris Zyp introduces Pintura, a server-side JavaScript framework that keeps the presentation on the client side where it belongs. Kris also wrote a Getting Started with Pintura article that’s worth a read. Pintura wins bonus points for running on node.js, Narwhal and Flusspferd. For those keeping score at home, that means that Pintura can run on SpiderMonkey, v8, Rhino and JavaScriptCore. That’s what CommonJS is all about!

Amazon Kindle: There’s An Active Content For That?

Amazon has announced a development kit for the Kindle, coming in February. The SDK will allow developers to create “active content”. Active content will certainly be different from iPhone apps, if for no reason other than the refresh rate of the eInk screen. Still, it’s an interesting development. Amazon has never said how many Kindles they’ve sold, but you can bet it’s less than the tens of millions of iPhone OS devices out there. You can sign up for the beta now.

Letters.app: Concept-driven Open Source

The Letters Icon

Most open source software begins its public life with code. It obviously started out as an idea and was built up following some need or desire, but by the time it’s public there’s some code. The currently-vaporous Mac mail client “Letters.app” started off with NetNewsWire developer Brent Simmons saying he wanted a better mail client. Macworld commented on the literally hundreds of email messages that followed. John Gruber was elected president for the 1.0 release, and Gus Mueller has taken on the technical leadership. Gus has also started a GitHub repository for Letters.app.

This is a really interesting way to start an open source project, and I wish them well. As has been pointed out on the mailing list, creating a better mail client has been tried before and failed. But, the leadership of the project is encouraging and this is certainly one to watch.

Fusebox Gives You Safely Extendable JS “Natives”

JavaScript is cool in that you can extend String or Array to add many conveniences. It’s not so cool in that others may do it for you, and in ways that are not quite what you want. If you’re willing to suffer through a bit of inconvenience (like declaring an array by calling fb.Array() rather than just []), Fusebox lets you extend native objects without impacting any other JavaScript code.

LuaJIT Gets Funded

It’s news to me that Google uses Lua internally, but they apparently do count Lua among the languages they use. Enough so that Google has pitched € 8,000 into the development of LuaJIT. Add to that Athena Capital Research’s € 12,000 and a couple of smaller donations, and you’ve got a successful funding drive. It’s great to see open source development supported so directly.

Realism In UI Design

Realism in UI Design is an excellent article for anyone who might be contemplating just using photos from iStockPhoto for their icons rather than having a custom icon set designed for their app. For everyone else, it’s a good read with some nice visual reinforcement about striking a balance in realism in your user interfaces. Also worth checking out is Mike Rundle’s article from December which provides some tips for getting subtly realistic user interfaces.

Bill Gates Joins the Internet World

BillG seems to be going all-in with a new Twitter account and a bloggy sort of site (The Gates Notes). Whatever you may think of Microsoft and Gates’ driving of Microsoft, it’s impossible to deny that he’s a big thinker and one worth following. Speaking of following, after just a day on Twitter he has nearly 250,000 followers. The welcome from Ashton Kutcher (4.4 million followers) no doubt helped, though it’s unclear to me just how much overlap there is between Ashton Kutcher fans and BillG devotees.

Notable Releases

• Firebug 1.5 was released ahead of Firefox 3.6 with a bunch of new features. This is notable, because Firebug would always lag Firefox releases in the past.
• Cassandra 0.5 includes improvements to multicore performance, the bootstrap process and adds the ability to decommission a live node.

> list
11 goto 11

Top 11 Most Anticipated Product Introductions This Week

11. Microsoft Ribbon Hero for the Xbox360.

10. Google Sock Search

1. CrunchPhone

The move toward real-time everything is wrong. We have enough interruptions in our days without having random links and news sprayed at us 24×7. Not to mention that there’s no real thought that goes into real time, and generally very little thought that gets compressed into 140 characters. Length also does not guarantee quality, and too much text can be a waste of time. The trick is to be concise.

I’ve adopted my SlowNews newsletter-like format for sharing and commenting on what’s going on in the software world. A weekly post for software developers and technically minded product managers. This is a way to keep up with interesting things that are happening, but through the lens of a weekly view where the uninteresting is edited away, the more interesting is promoted to the top and a bit of commentary ties it all together.

SlowNews is a chance for me to gather my thoughts and to review the truly interesting things that are going on in software product creation.

Blue Sky On Mars SlowNews is published on Tuesday mornings at 9am Eastern time.

This is just a test post while I’m setting things up.

Last night was the third a2div meeting. Majd Taby spoke about SproutCore at the inaugural meeting in September, and I spoke about CommonJS in October. November’s meeting, which was to be about Google’s Closure library, was canceled because of a confluence of factors… Three JS talks in a row led Trek Glowacki to declare that

so far a2 <div> has turned out to be “A2 Javascript Lovefest”

While I certainly like JavaScript, that wasn’t intentional. We have to run with what people want to hear and are willing to talk about. Luckily for us, Trek himself was prepared to do something about it and gave a great talk last night about Heroku.

Trek had a demo ready to go, involving getting the open source code for RubyFlow running and customized. He had a neat way of doing the demo without resorting to live coding: he had the demo code in a git repository with separate branches for each step of the demo. It worked quite well and Heroku looks awesome. Video of the demo is available online.

In the loosely structured part of the meeting that followed, we had bits of discussion about a few different things, including a quick demo of Node.js by Majd. We also talked about what topics we’d like to hear more about in future meetings. Here’s the list that came up:

• Comparison of NoSQL engines
• Node.js or other Comet serving technologies
• The Microsoft stack for web development (Jay Harris offered to talk on this topic)
• Something involving designers + programmers (maybe even a “basic principles of design” intro to help us avoid creating designs with misaligned bits and eye bleed inducing colors)

The January meeting will be at its usual time and place (January 28th, 7PM, SRT Solutions). Topic to be decided.

Thanks to Trek for a great meeting at the spiffy Workantile Exchange!

This post is a collection of random thoughts about the Bespin Reboot project so far.

The past summer, the Bespin team at Mozilla (Ben, Dion, Joe and me) started thinking that the time had come to make some significant changes to the Bespin project code. These changes would make it easier for others to use and contribute to Bespin and also make it easier for Bespin core contributors to add new features. We did a collection of releases during the summer and then slammed on the brakes for what we’ve called the “Reboot“.

The Reboot involves a serious refactoring of the code, plus changes in priorities and processes. We started fresh with a new source code repository (two, actually, since the Python server has been pushed into a separate repo). Then, we poured the code from the old repository into a new structure of CommonJS modules. We changed our underlying GUI framework to use SproutCore, so that we could spend less time thinking about getting things on the screen and more time with features that help people write their code.

Once you get into the groove of doing releases and adding good stuff for your users, it’s really painful to stop doing releases. I’ve been itching to ship since the beginning of October when we shifted full-time to the Reboot repository. Our goal all along has been to get the editor running again as soon as possible. Our initial thought was “get it running on a mix of old infrastructure and new and evolve from there over time”. That was a nice thought, but it didn’t work out very well that way.

SproutCore’s event model is based on adding a small number of global event listeners and delegating events to the proper components. Bespin had been using Dojo with the far more common model of attaching events to DOM nodes directly. In order to take advantage of what SproutCore has to offer, we very quickly ended up on the slippery slope of doing other refactorings to the editor, which is something we had not initially planned to do.

I’m thankful that we decided to go ahead with those changes, though! For example, the editor’s event handlers all had code in them to figure out “is the cursor over the scrollbars?” because the editor itself was responsible for painting the scrollbars! The editor had one canvas and it managed everything on there itself. We had discussed the possibility of using the Thunderhead project to manage the different pieces that appear in the editor canvas, but we’re a small team and don’t have time to work on a GUI toolkit in addition to our other ambitions for Bespin.

And so it came to pass that we started down the road of refactoring the editor into separate SproutCore components. Patrick Walton joined Mozilla last month and immediately dove into the task of breaking the scrollbars out into separate components. In the process, Bespin’s editor is now a scrollable SproutCore component, so you could even use the standard scrollbars with the editor. Bespin’s scrollbars are a bit tricky, though… rather than living just outside of the scrolled area, they are actually drawn on top of the scrolled area. We also found that the gutter of the editor really should be a separate component (or maybe even more than one), which is why the horizontal scrollbar is not positioned properly right now. Patrick is actively working on fixing that.

Meanwhile, Joe has been hard at work fixing lots of other things: random uses of Dojo, how our singleton components are managed (since we ultimately want to be able to support multiple editors on a single page), copy and paste issues, etc. I’ve spent a bunch of time working through building, module loading and documentation issues.

From where we sit now, the code is shaping up quite nicely. Soon enough, if you have a SproutCore app, you’ll be able to just drop an editor right into your app. As of today, anyone with a website can grab a copy of Bespin and include the editor component very simply in their pages. We figure that we’ve got another month of work to do before we’re ready to update bespin.mozilla.com. We have a whole bunch of features to port over from the old code and we need to make good on another big part of the Reboot promise: opening Bespin up for plugins. It’s been hard even for Bespin core people to contribute because of the state of the code, and I’m looking forward to getting past that hurdle soon. Before I know it, we’ll be back to shipping new features regularly (and quicker than before!) at bespin.mozilla.com. I can’t wait!

I’ve always thought that it should be possible to design a language that is both usable and performant. JavaScript performance has improved tremendously, but it is still quite a distance behind C and even Java. Of course, programmer productivity is certainly more important than raw performance for most applications. It’s only as you try to scale up services that you really wish you could squeeze out more performance. In fact, being able to squeeze out more performance is one way to avoid the complexity shift of moving from one box to two/many. Of course, there’s always an upperbound to this, but that upperbound can be remarkably high.

I always thought that D looked like the language that could unify high level programming and performance. But D has failed to catch on and seems to be in a state that would make anyone seriously question using the language for real work.

Now, along comes Go, a new language sponsored by Google. More interesting than the Google part, is that Go was created by people with a long history dating back to the origins of Unix (Rob Pike, Ken Thomson, apparently even Brian Kernighan are involved). The language is designed to support super fast compilation (yay for programmer ergonomics!) and C-like performance. Importantly, the language also has built in features to help support scalable and safe concurrent programming, via “channels” for passing data back and forth, rather than something like transactional memory.

Go has a simplified object model that looks cool, but I’d be curious to see how it feels to use in practice. Go doesn’t have exceptions, which seems like a real drag to me. Apparently, exceptions are still considered an open issue and they present thorny issues when you’re dealing with concurrent processes.

Go’s standard library looks to have a decent collection of features, and you can call C code pretty easily. More care needs to be taken if you want C code to call into Go. If Go can get its packaging story together more quickly than Python has, it may indeed start having appeal as a high-level, fast, concurrent programming language.

It’s still very early for Go. It’s not used in production in Google yet. It doesn’t run on Windows. But it has arrived on the scene hitting many points at the “good enough” level (fast compiler, decent library, ok interface to C, decent docs). Google has full-time staff assigned to it, and they’re even hiring a program manager. With speculation that Google doesn’t want to use Python for their high volume services, I wouldn’t be surprised to hear that Google really wants to use Go internally. With an “anchor tenant” like Google, Go has a lot more potential than D ever had.

Now they just need to deal with the pesky issue of the name.

Due to Thanksgiving falling on the same day as the normally scheduled date for a2 <div>’s monthly meeting, we decided to find a different date and possibly join up with another group for a complementary topic. And, indeed, that’s what we’ve done!

a2 <div> and the Google Technology User Group will have a joint meeting on Tuesday, November 17th. The meeting will be at the SRT Solutions office at 7PM. I realize that there are conflicts that day, but there is so much going on during the month that it’s hard to find a date without conflicts!

We have a hot topic: Google Closure. Sure, new JavaScript libraries appear every day, but not like this one. Closure has a maturity that comes from years of use within Google, on some of Google’s busiest properties. It has an amazing toolset (Firebug plugins, super squishy compiler), great docs and a nice collection of features. Of course, not many people outside of Google know much about Closure right now, so this meeting is a group exploration of Closure. Read more in the RSVP form below to see how it works.

I hope to see you there!

For the second a2 <div> meeting, I’ll be talking about CommonJS: JavaScript everywhere. There’s more information on the form below. As with the first meeting, the meeting will be at 7PM on the 4th Thursday of the month at SRT Solutions in downtown Ann Arbor. That’s October 22nd @ 7PM (see the a2div site for more information).