In what has to be the oddest domain situation I’ve read about in a long time, it seems like someone formed 9 companies, named “1 Limited”, “2 Limited”, through to “9 Limited”, started using the .ltd.uk domain for each one, then applied for a trademark for each company name, all to get the domain names 1.co.uk through to 9.co.uk.

The domain names themselves were auctioned last year by Nominet, the UK domain name managers, and the extraordinary steps take to acquire the domain names have come to light in a Nominet DRS appeal for the 9.co.uk domain.

In the appeal, handled by an independant solicitor for Nominet, the full details of the process are laid out, and in it the complainant says that the company “9 Limited” will be shut down if the domain is not handed over. The complainant did attempt to buy the domains at auction, but was outbid for 9.co.uk (and others) by the eventual owner.

Fortunately, it seems a sensible decision was taken by the Nominet Expert:

7. Decision
In light of the foregoing findings, namely that the Complainant has Rights in a name which is identical to the Domain Name, but has failed to show that the Domain Names, in the hands of the Respondent, is an Abusive Registration, I direct that no action is taken in relation to the Domain Name.

I’ve spent some time recently updating a script I initially wrote in Python, which handles network communication between a client and 2 servers, with a response from server A triggering an SSL connection to server B from the client. The script needed to be fairly low latency, but didn’t really do much.

Python worked, but was definitely slower than I wanted around the SSL side of things, and I wanted to see if anything could be done about it.

First, I re-wrote it in node, mostly as a way to learn how it worked, and partly because it seemed like node was a good fit. After a few days of hacking around, the program ran, was fast enough (certainly faster around SSL, I’m not sure why), and was a good learning experience. But then, I kept seeing some odd issues, where a message wouldn’t be processed for up to 500ms, or was seemingly received twice. After learning some more Javascript, it became obvious that my code needed tightening up and re-thinking in some areas, to work correctly with the asyncronous nature of Javascript.

I could almost certainly have fixed it, but now that I’ve learnt more about node and Javascript I’m not sure the problem was that great a fit after all – it’ll certainly work, but node would be a better tool if the client needed to query 100 servers and handle 1000 responses in short order, not 1 response as quickly as possible.

As an aside, I also tried erlang, but the documentation went over my head, I’m obviously not cut out to be an Erlang programmer. I got the basics of my code to work, but I was never sure if I had things right, so I moved on.

This got me looking around – what’s high performance, doesn’t have a huge learning curve, and works well when it comes to networking. The answer I came up with was Go, one of seemingly dozens of programming languages coming out of Google.

Go is described as

an open source project to make programmers more productive. Go is expressive, concise, clean, and efficient.

but Google might be better of describing it as

Faster code for people who write scripts.

It’s fast, easy to understand, has some really nice features (GoRoutines are as clever as their name), and I was up and running in a day. Go’s file handling is rubbish if you’re used to scripting languages, but that was a one off issue for me, and the rest of the libraries have worked really well.

While all performance is subjective, and all benchmarking is best done yourself, latency is now much lower than the original Python version, slightly lower (and more consistent) than the node version, and nothing’s fallen over yet.

My conclusion is simple: If you need to speed up a script, try re-writing it in Go!