As if I wasn't bored enough, I've written a proof-of-concept blog using Go, that new language out of Google. I blogged about this language before, but I wanted to give it a real test drive, so I came up with this.

goblog on github

Pointers ahoy

The first thing I noticed when I got started was pointer trouble on my part. Go still has pointers like in C, but some of the syntax smooths over the differences. Compare this C code

typedef struct point {
    int x, y;
};
point p;
point *pp = &p;
pp->x = 5;    // !!!!
(*pp).x = 5;    // !!!!

to this Go code

type point struct {
    x, y int;
}
var p point;
var pp *point = &p;
point.x = 5;    // !!!!

That is, Go field access via pointers is identical to field access full stop. Like that semi-colon thing I mentioned previously, it's one of those things that trips me up out of habit of the old language.

Reverse iteration

... or lack thereof. I haven't found anything about how to go through something backwards without screwing around with indexed access myself. This was important because the blog entries are appended in order, but the best way to present the front page was with the most recent entries first, i.e. the reverse of how it's stored.

Operator overloading

I wouldn't never have imagined something like this even being on the horizon when writing the code for a blog, but apparently I was wrong.

If you define a type that's based on a slice, you can't use any more slicey techniques on it. That is, this

type Entries []Entry;

stops me from doing these

var es Entries;
// some initialisation for es
len(es)
cap(es)
es[0:len(es) + 1]

I understand that it makes sense, but honestly, I just wanted to add a couple of methods on a slice of a given type. No dice.

Read the docs

This one's my bad. I spent about 45 minutes writing a resizable-slice-with-underlying-array implementation to store an ever-growing amount of entries and comments.

And then I discovered collection/vector.

Well crap. At least it saved me a lot of code in the end, even if I had to delete the bulk of it.

Multi-tech drifting

In this effort, I screwed around with learning:

• Go (duh)
• json-templates - the template language AND the Go API
• HTML 5 - the semantic kind of markup, read the blog page sources when you try it and you'll see what I mean (special thanks to Mark Pilgrim)

After all that, I can safely say I'm an expert in none of them. But we are all a little bit more familiar for the time.

Django-ish separations

Being a Django newbie, I thought it'd be fun to split up the blog's design the same way Django does with it's app design. You can see it in the names of the files: "models.go", "views.go", "templates/index.html", "templates/entry.html". For the most part it worked out well.

The URL pattern matching of the default HTTP dispatcher doesn't support regular expressions, let alone group matching. How it works is that it matches on the longest prefix matching the URL string, and then shuffles the connection and request to a handling function.

This caused problems for viewing single blog entries. The ID of the entry is held in the URL, so without regexps, I had to shuffle it off based on "/blog/entry/" and split the number out myself in the views.Entry function. So much for separation of concerns.

The other problem was when I needed to redirect after the user posted a new entry or comment. The normal course of action after form submissions like that is to redirect to a sensible page. I couldn't do that without writing the URL directly into the Location HTTP header. Django lets you perform a "reverse lookup", where you instead state the function, and Django discovers the URL, so no URL-ish stuff seeps into your view code. I couldn't do that here either.

In the end

Well, I'm done with this. Anybody who wants to do something with it, be my guest. It only took me a few hours after some false starts and rickety moments. Wonder what I'll come up with next?