Replacing Rails: Part 2 - Amazing Tooling
I come from a compiled language background (C, Objective-C) and I've been thinking for some time now that Rails isn't always the best tool for the job. Memory usage, performance, deployment and too much "magic" are an example of some of Rails' weak points, points I find to be of great importance in the larger scale apps I've had to write or maintain.
I remember reading the initial release of Go and being excited! A statically typed language with garbage collection, a compiled language where concurrency is a first class citizen and a standard library which has everything you could ever need, 90% of what you need is already there.
Here's the workflow and tooling I've been using recently with Go.
Rake Tasks
One of the most useful parts of Rails is Rake, designed by the late Jim Weirich it's essentially make but based in Ruby, the advantage being that you can run tasks in your native language, letting you manipulate data and state with your current app.
I love Makefiles. Most of my projects Ruby or otherwise seem to have a Makefile these days. I'm not sure why people seem to be scared of Makefiles; the syntax is easy, though I suppose the documentation at times is a little cryptic.
Famous Rails commands include rake db:migrate and rake test but these are simple to replace.
Database migrations are definitely a divisive and controversial topic amongst back enders but Rails has them and I've found that generally they are great, especially during development. There are several alternatives out there however, including ones that aren't even written in Go. We've been using Goose but I've added a few tasks to our Makefile that just use the wonderful built in PostgreSQL commands.
Testing via rake test has been replaced by Go's built in test command and library which is of a similar quality to Ruby's built in test library in that you might want some more assertions or similar, but these can still be invoked by the command go test
Generators via rake generate model x are missing in my workflow, but to be honest I wasn't a big user anyway since I seemed to spend more time removing the cruft than I would have done writing the original by hand, especially in such a terse language as Ruby.
When you're writing in Go you will spend quite a bit of time writing structs, especially when handling JSON. I noticed there are some tools like gojson out there to help you though!
Go fmt
If there is only one thing you take away from reading these posts, it should that go fmt is totally amazing. I kinda wish it existed for all my favourite languages!
Essentially you run go fmt on your code and your code is magically all perfectly formatted and conforms to the Go guidelines for writing code! Here's what the Go creators have to say about it.
Specifically I agree with the following points!
- easier to write: never worry about minor formatting concerns while hacking away,
- easier to read: when all code looks the same you need not mentally convert others' formatting style into something you can understand.
- easier to maintain: mechanical changes to the source don't cause unrelated changes to the file's formatting; diffs show only the real changes.
- uncontroversial: never have a debate about spacing or brace position ever again!
And this is how it looks in real life..
If you think go fmt is cool then checkout go imports! It's a great tool that blew my mind and made me super happy when I discovered it.
"This tool updates your Go import lines, adding missing ones and removing unreferenced ones."
If you've ever been debugging in Go only to be constantly interrupted by the compiler asking for you to remove or add the "log" import then this is for you!
Here's go imports working in real life via the great vim-go plugin..
Asset pipeline
I'm not going to talk about this for too long but I do understand that for many developers Rails' asset pipeline is very useful. We tend to favour our own stack, however, using tools like Browserify, Gulp and of course Makefiles.
Essentially nothing for us has changed when moving to Go in this area, as our Makefile or Gulpfile comes with us. In some ways it can be easier since we no longer have to remove the asset pipeline from Rails each time we start development.
What's next?
In part 3 we'll talk about deployment and cross compiling your Go code to run on AWS or other environments. Perhaps we'll even talk about job queues and long running tasks!
What are the tools you would miss? Let me know via @alexrbarlow or talk on our HN comment thread here https://news.ycombinator.com/item?id=9465687
Continue reading
Getting started with Swift and WatchKit
In the second of my blogs on Swift I will look at WatchKit for the newly released Apple Watch. This will involve adding Watch functionality to an existing...
Apple Watch: What can you do with it?
I’ve been lucky enough to get hold of an actual physical Apple Watch now since Friday. I’ve worn it over the weekend and of course, played around with bui...
Replacing Rails: Part 1 "Lets Go!"
Rails has been, whether I like it or not, a pretty big chunk of my life. When I first started charging for my work, Rails was new and it seemed like a com...