Anything that could be written in Go…
To a few people, they might know me for the RxGo library I wrote. To even fewer who have followed the project, they might know that I have not been as active as I’d (and they’d) to. That’s a story for another time, but in short I had said goodbye to Go a few months back for a few personal and professional reasons.
Now here I am, writing about Go again, this time not as an open source developer but as a user who is using it to build something. And one and probably the only takeaway I’d like to give is this:
Whatever you could build with Flask or Node.js, you could probably build with Go faster.
I have been building an API backend in Python/Flask, mainly because I’ve been using Python at work. However, I quickly hit the Cliff of Dread — the point where you productivity drastically drops for a period of more than a day. This is because of two things (there might be more, but these are the main obstacles I’ve faced):
Interpreted Python code makes module / package frustrating
This is especially true in Flask, whose documentation offered many ways of organizing the project, including putting initialization code in the __init__.py of a package, which makes importing inconsistent and weird.
Duck-typing makes a fool out of anyone at some point
Duck-typing in Python may sound great at first, but it quickly becomes burdening to read and make sense of. Duck-typing simple saying is “If it quacks like a duck…”. Well, in Python, you can’t even tell if a value is a duck until either it quacks at or growls at run time. Duck-typing is better when there’s actually some notion of type interfaces, not just an object type.
BONUS: Space as relevancy
Some really dread this, and although it didn’t necessarily throw me off, I did encounter a time when the interpreter complained because my IDE magically mixed tabs and spaces. Go takes an unconventional (and sarcastic) convention of using 8-space tabs for indentation, although it doesn’t care if spaces or tabs are used.
Go does excel on these two points. I wrote about how easy Go package system is. In fact, it’s the first and only language I know that anyone could whip up a multi-file package in no time and her code will run. All you have to do is make sure some environment variables like GOPATH is set properly. There could be an issue down the road when deploying, but it’s way more important to not hit the cliff early on.
Go code is so easy to read, simply because it has very simple type system. For instance, the add function in Python below could work for numbers or strings, but not both.
# Python
def add(x, y):
return x + y>> add(1, 2) # 3
>> add(1., 2) # 3.0
>> add('foo', 'ey') # 'fooey'
>> add('foo', 1)
TypeError: unsupported operand type(s) for +: 'int' and 'str'
This fact simply means that this function can go on working for sometime without throwing this error. To be defensive, you might even throw in a try-catch statement or check x and y ‘s types before even do anything, but what’s the point if only you could know beforehand that it only worked with numbers?
(In a more meta language like Ruby, operator like + is a function which means that it could be extended to work for any type in the way that the user likes, and that’s not necessarily a good thing, but at least it has that extendability of duck-typing.)
In Go, it’s just very explicit:
func add(x, y int) int {
return x + y
}func addFloats(x, y float32) float32 {
return x + y
}
So add('foo', 1) will throw an error at compile time right away and won’t just get out in the wild. Boilerplates? Yes, definitely. But interesting enough, most of the time when there’s a need to write an add function to add two numbers, normally all you need is just that.
Lastly, I am beginning to see that Go design encourages the getting the job done mentality instead of crafting the perfect code abstraction. This is something I didn’t see when I was writing RxGo, but I’m beginning to appreciate more and more as with every iteration my Go code just keep building.
