Choosing Go to implement the new GOV.UK router

In their defense having worked on sorting out problems on old complex large scale publishers sites. If your trying to make a collection of services hang together in a seamless way you do need some sort of front end to tie it all together and that needs to be usable by non gurus.

Though they do seem to be using all the new toys maybe a bit more thought about which technology to use rather than jumping from technology to technology.

I tend to agree. The post makes a point of saying "we had a router built in scala, but no one on the team knew how to maintain it".

It seems they're allowing team members to play with "language of the week" (lotw), build something that's then used in production without the rest of the team knowing the lotw, that member moving on and then rebuilding it in a new lotw 6 months later. no doubt this GO implementation will go the same way at a later date.

I'm not opposed to using a lotw in production with other languages and such, but it needs to be done in a thought out manner with the whole "what if the project lead gets hit by a big red double decker" mentality.

It does not look that bad actually. Your list lacks Oracle, Microsoft technologies to really complain about inefficient usage of public money. I would love if my country used open source more.

We did have some configuration - it was stored in Varnish and Nginx. The time cost of shipping new redirects when content is moved or new routing configuration for new tools coming online is non-negligible, particularly as we're in the middle of moving 300+ government agencies onto the GOV.UK platform. Also having all those redirects, friendly URLs, and application mappings in static configuration makes self-service publishing tools very difficult to build.

This is all outlined in the blog post - perhaps not as clearly as I would have liked, though!

Presumably by having a list of different technologies they are taking the approach of right tool for the job. The obvious side affect also being that engineers who work on this need to be polyglot as opposed to any specific tech. I certainly categorise this as a good thing, a developer and as a stakeholder (UK resident and user of the site).

And yet it works better than most traditional Government IT projects. Healthcare.gov, I'm looking at you.

The UK government is a 19th Century 'filing cabinet bandwidth' information architecture. The IT systems as always reflect the organisation structure that produces them. The data redundancy and unnecessary domain separation is frustrating and archaic.

Uk.gov is just the cherry on the top of an old and creaky enterprise design that hasn't kept pace with changes to its mission or the world around it.

I wonder if the technology churn is more of an issue with the structure and organisation of GOV.UK rather than a technical one. In the post he states that the previous router was unmaintainable as there was no-one with a deep knowledge of Scala in the team and that this was the main reason for the re-write. Why was this allowed to happen? Is there a rapid/high turn over of staff or are teams moved around without regard for skill balance?

Yes, but this time they have really found the silver bullet (honestly!).

... something something blub something something agile rockstar ...

I'm not sure why you have such a negative attitude towards gov.uk, the site seems refreshingly good at it's job. It's simple, clear and easy to use. As long as they can execute fast what does the tech stack matter?

In this case NIH resulted in a space-optimized algorithm, rather than a time-optimized one. So well done there, kids.

Not impressed. Seriously, this is just awful.

People make changes to their infrastructure. The govuk team are at least brave enough to blog about it, and offer the code up for inspection. Can you post links to similar public contributions you have made?

I'm sure if you joined the team you'd wave your magic wand and everyone would fall in line, and things would be beautiful. Right.

Oh, and I'm sure the golang community are really, really pleased that "in fact, [you] like it" - very charitable of you!

I can't wait to see what you've been up to.

You're right, but i think the point you're missing (and i don't mean this in a rude way) is that they had a system built in scala, somehow, but now no one on the team knows scala.

They lack an architectural oversight, that they should really be using one(ish) language rather than a big mix of languages so that this doesn't occur again when no one on the team knows GO because the project leads taken a new job.

"Big is beautiful" versus "small is beautiful". Some people like Ruby, others like Python.

Hell, some people like Perl! :p

This, whilst likely true, is not a self-evident fact.

I think the argument in the blog post is weak because it does not quantify what makes Go more suitable for learning than say, Erlang or Clojure, which are dismissed outright, before moving on to discuss some of the advantages of Go in depth.

If Scala and Go were the only two technologies mentioned you would have a point. But this is a monstrous fad bloated lineup of technologies they have there. Integrating this mess is way way more complex than any individual language.

There are good arguments for trying new technologies, but this particular instance seems to be a very good example of how such a strategy can go terribly wrong.

[Edit] On second thought, I might be jumping to conslusions as I don't know anything about how successful they are in actually achieving their goals, doing it on budget or how fun it is to work there. Their actual approach may be less confused than the blog post makes it sound.

I like Erlang, but in shops I've worked with that have your "average" dev in it, it's syntax and semantics would be something they struggle with (if it ain't PHP, they'll struggle with it...). Unfortunately I don't blame them. That said, I think if they truly needed to build a somewhat stateful concurrent router, Erlang is a better choice (solely because it's battle tested in those highly concurrent workloads). Picking tech for big things like this when you have to balance a teams knowledge with the right tool is a hard problem in my experience.

I agree, but if you want to learn something today then GO would fit better for the task at hand and easier to learn. That and the cost involved is really good value given the training involved with learning Scala over GO.

That and I suspect there was some wishlists on what people wanted to do in the mix, like COBOL, still used but people just do not want to learn that as it is deemed so last century in comparsision to say java, though they are altogether different fish. Bit like the difference between a proxy and a router, what sounds better on a CV.

I suspect that from a maintenance aspect that the GO code will be much easier to support and grow as and when needed as well as scaleability.

Still it is most encouraging to see such a young language like GO get so much respect and use so quickly in a enviroment that has to many in the past and present been slow to adapts new technology. But there again many Govermental departments still have XP, albeit used as a fancy terminal to some old mainframe application that just ticks along.

You should read the first article in the series - https://gdstechnology.blog.gov.uk/2013/12/05/building-a-new-...

> But the first statement, literally, does not make sense on its own.

Why? There are other resources than CPU time, e.g. memory.

> and particularly how the old router worked

Oh, then it's OK. It's always reasonable and a safe bet to rewrite something instead of understanding how something works, because after all, your predecessors were a dumb bunch and you (using Go! how cool is that!?) obviously know much more.

I asked on twitter, and got a reasonable response. Investing in learning Scala is a much longer term thing than learning Go (which is, in their experience, a much quicker thing to do).

I'd far, far rather relearn Go than relearn Scala...

Given that Scala is far more complex, learning Go from scratch is probably a lesser task.

How did they come to choose Scalatra if nobody knows how to use Scala?

I'm a big fan of Go and we use it internally, but I too wonder why nginx + Lua wouldn't be the chosen path.

If it's good enough for Cloudflare it probably is good enough here.

Besides, Varnish also would have excelled (yes I read the first post in the series) if they had just stored the configuration in a saner format and then output the required VCL when the config changed and reloaded on the fly.

Both of the technologies I would've picked (nginx and Varnish) were in their stack.

I love working in Go, but reading this feels like a reinvention of the wheel. Go would be my choice only if these other things didn't exist already and you had to start from scratch.

The biggest pain identified was the writing, maintaining and loading of the router config. Openresty could've solved that.

F# and Nemerle are both based on the CLR, and unfortunately the performance of Mono is pretty bad, and not really suitable yet for high performance use-cases like this.

Also I'd Erlang is state of the art, even though it is so old (Haskell too), but I wouldn't call it an entirely safe bet because it requires quite a different style of programming and experience, so might not work well for certain developers.