Hopefully by now our customers and readers will know we like to do things a little differently. We're a relatively new company, but from a long pedigree of hosting and technology companies. We like to build the functionality that our customers want and we want to be honest. So with that in mind, the audio fades in and you can hear my opening sentence at the Developers Anonymous meeting...

My name is Andy and I made a technology mistake

As a developer I'm sure you know this feeling - you read about some new technology and think "that is awesome and cool, I want to use that so badly!". Then the more experienced developers among us hopefully put it out of our mind, until the moment arises and you just know, deep down in your soul, that the new cool technology you read about would be a perfect fit for a new greenfield project you're about to start.

Well, that describes me in about September 2015. I'd recently been reading about Go and all the benefits such as really high concurrency, the low memory usage of the resulting daemons and really clean code. The time came to write an API for what would eventually be the core of Civo, so I weighed up the technical benefits of using Go against our default choice of technology Ruby on Rails (something I have over a decade's experience in).

Go was a clear winner in terms of technology choice, and hell, I'll admit it - much cooler! So I set to work building an API server in a language I barely knew, while working on other projects alongside it.

How did that work out for ya?

To be honest, it was great! The project ended up working really well, we launched a cloud hosting service for one of our clients using it, then launched our own Civo product also using it. Performance was crazy fast, resource usage low, the functionality worked really well and everyone was happy! Sure there weren't really many automated tests (testing in Go is a nightmare compared to using RSpec with Rails) outside of a few end-to-end scripts that exercised it but the functionality worked really well and the project was definitely considered a success.

However, there were two undeniable problems with the choice of technology. Firstly and most obviously, I am a newbie to the Go language so therefore naturally it was much slower to develop new functionality in the API codebase than it would be if it was written in Rails. Secondly, and this was the biggie - no one else on the team knew Go at all!

So, while my family holiday was rapidly approaching, I realised that I'd be the only one able to support the API while I was away. Lots of things have been written about automatically deleting all emails while away on holiday (for example the 2014 opinion piece in the New York Times), but I was in a worse situation than just coming back to a load of emails - I was on the hook for ensuring the API was working every day of my vacation. Not ideal for my wife/children and while I love our users, this isn't something I wanted to feel forced to do.

The solution

There are lots of articles out there on people choosing Go over Ruby on Rails, even rewriting existing projects from Rails to Go, but we may be one of the first to go from Go to Rails. It's taken about 6 weeks of full time effort (plus quite a few weeks before that of evenings/weekends/spare time) but we've finally launched it this week.

I can imagine the fact that we've changed a core part of our infrastructure comes as a surprise to many of you, because it was intentionally kept interface compatible. Of course, there were a few hiccups in the first couple of hours and I'm sure there'll still be a couple of teething problems over the next couple of weeks, but in general the new Rails 5.1 codebase is tested to be interface-compatible with the old Go 1.7 codebase and is working as expected.

We've gone from 14,000 lines of Go code to 3,000 lines of Rails code (plus a further 5,000 lines of test code, covering some 800 test cases and covering 97%+ of the code). And now I have a team of people that can all support the API! We have Rails developers of course, but our Cloud Engineering Team and Frontend Developer also know Rails.

So, now the big rewrite is live that means we can now start to get to work on your suggestions, so if you have any you really want us to work on first, get your suggestions or votes in.

Thanks for bearing with us. I'd like to say this will be my/our last mistake, but given our love for honesty and openness, I couldn't even think of bringing myself to say it.