Live data from Hacker News

Choosing Go to implement the new GOV.UK router

gdstechnology.blog.gov.uk

21–30 of 98 posts

Re: Choosing Go to implement the new GOV.UK router

#21

As they are Using Nginx already interested to know if they ruled out openresty or did not consider it.

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.

Re: Choosing Go to implement the new GOV.UK router

#22
post #16
post #8

Earlier quoted context omitted.

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

I actually read that and thought nginx/mod_proxy. Looks like they didn't actually try it or know about it which is worrying. Either that or it was more interesting to do it in Go which is not a valid reason in a taxpayer funded site.

Dynamic route updating with nginx is not fun.

Re: Choosing Go to implement the new GOV.UK router

#23
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

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).

Actually they're using the wrong tools for the job because they're having to rewrite bits regularly in different tech. There is obviously no evaluation taking place.

Establishing technical standards and homogenity is important on projects of this scale.

Re: Choosing Go to implement the new GOV.UK router

#25
post #22
post #16

Earlier quoted context omitted.

I actually read that and thought nginx/mod_proxy. Looks like they didn't actually try it or know about it which is worrying. Either that or it was more interesting to do it in Go which is not a valid reason in a taxpayer funded site.

Dynamic route updating with nginx is not fun.

No but updating static routes via puppet/ansible and reloading is a piece of piss.

If your site is volatile enough that the routing needs to change that often then there is something wrong either with your information architecture or your development process.

Re: Choosing Go to implement the new GOV.UK router

#26
post #14

Earlier quoted context omitted.

Agree entirely there! However it doesn't excuse people working on a web site funded by the taxpayer using it as a technology playground.

In their defence, gov.uk is miles better than just about any other government site/application I've ever used.

Oh definitely agree. I'm not dissing the site itself which is marvellous so far, but the technology churn is very concerning.

Re: Choosing Go to implement the new GOV.UK router

#27
post #16
post #8

Earlier quoted context omitted.

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

I actually read that and thought nginx/mod_proxy. Looks like they didn't actually try it or know about it which is worrying. Either that or it was more interesting to do it in Go which is not a valid reason in a taxpayer funded site.

[deleted]

Re: Choosing Go to implement the new GOV.UK router

#28
post #18

A lot of the comments here seem to be missing something quite important: Scala and Go are not similar languages. Scala is a large and complex language, encompassing multiple programming idioms. Teams programming Scala (as with C++ and many other "large" languages) often have difficulties nailing down what portion of the language they are going to use. "Java-without-semicolons" all the way through to idiomatic, functi…

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.

Re: Choosing Go to implement the new GOV.UK router

#29
post #13
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

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.

Depends if they have open source support contacts or not. They can be just as much as buying the commercial equivalent.

Re: Choosing Go to implement the new GOV.UK router

#30
post #25
post #22

Earlier quoted context omitted.

Dynamic route updating with nginx is not fun.

No but updating static routes via puppet/ansible and reloading is a piece of piss. If your site is volatile enough that the routing needs to change that often then there is something wrong either with your information architecture or your development process.

Or maybe you're trying to deal with a huge legacy content migration of several hundred different government agencies and want to deploy several times a day without waiting for 10 minutes for nginx to load 1MB of config each time?
Post reply on HN