Live data from Hacker News

Choosing Go to implement the new GOV.UK router

gdstechnology.blog.gov.uk

81–90 of 98 posts

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

#81
post #76

Earlier quoted context omitted.

£6400 wouldn't even pay for the coffee and biscuits on the typical UK government IT project.

Nearly 4 duck houses though!

And not even a full week billing for a big 4 management consultant.

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

#82
post #57
post #9

Earlier quoted context omitted.

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

Because you always need to use all the features the language provides. Simpler -> limited.

C is much simpler than Scala, is it more limited?

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

#83
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.…

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?

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

#84

Earlier quoted context omitted.

Yes because a real world organization with IT systems going back 50+ years is exactly like some me to macbook and MBA start up with two men and a pantomime horse in old street.

Yes because a hipster startup in Old Street is the only kind of non-government entity that uses computers for anything.

Well not everyone is good at it at BT is/was well before that fuckwit sales man got over promoted and fucked over Global Services good and propper.

And at least they have avoided any healthcare.gov and RBS fiascos - Though I suspect that Universal credit is going to be a real CF

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

#85
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.…

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

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

#86
post #83
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.…

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?

I think the site is good. I have no problem with the technology ultimately but to put a fine point on it, I'm not paying the government lots of money to invent their own infrastructure components when perfectly good ones exist already.

The same applies to people working under me.

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

#87
post #83
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.…

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?

Try doing something with it (eg apply for a tax disk). At that point it always hands back control to the old site(s) it "replaced".

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

#88
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…

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.

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

#90
post #20

Earlier quoted context omitted.

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…

They're incredibly easy to build. I notice you use puppet. That's enough tooling to push configuration out and restart services for nginx or apache+mod_proxy. You can break configuration out into separate files per agency if you need to. Varnish is different as that requires restarting. We do the same with commercial kit (Riverbed) with over 140 HTTP application endpoints and that is higher friction than the equivale…

There is a need for dynamic routing, which you're overlooking. So updating configuration files and restarting services would not work.
Post reply on HN