Golang is agnostic to particular programming paradigms. Here’s why.
A Long Story Short
the Novel Coronavirus is now travelling the world. Some countries decided to lockdown cities that are infected by this most infectious virus of the year. It’s also a month where I spend the spare time as a temporary jobless man after resigning from Tokopedia, the largest e-commerce platform in Indonesia.
It is taking me to a tranquil state where no surrounding crowds, voices, or whatever they are that bring you to focus less on something you’re working on. So, I hear the void is whispering to me: How about writing a functional programming stuff?
Golang has been my favourite language, at least until now. Previous working experience had me to deal with it, we get to know each other better day by day. I like its simplicity and straightforwardness; it’s like you are the master who can tinker and mix-match whatever you want to build anything on this language.
I’ve created a tiny library in Golang to emphasize its agnosticism of particular programming paradigms to you. In the instance that it doesn’t only belong to Object-Oriented Programming paradigm which everyone usually glorifies (hey, me too!).
I called the library as Fun-go (still far away from perfect) that will provide some functional programming ability in Go. Basically, it consists of map, filter, and reduce function that I adopted from Javascript. Well, it’s quite influential enough while I was working on it besides my confession that:
I do really hate repetitive looping syntax!
I will start with a pain point and describe how the library will help me a lot getting rid of my hatred on that thing and make Golang still loveable.
Searching Items is Painful
Searching is a basic instinct in computer science. Oftentimes, a simple thing becomes more complex because we alone that add more complexities to it; like too many searching conditions. Example:
- Search products with price higher than $50
- Search new products with price higher than $50
- Search used products that each has ID greater than 1234 and price lower than $100
- Another search condition…
- Etc…
In a conventional way, your code will usually look like this:
You must see a pattern. You keep writing many repetitive looping blocks over and over again and starting losing the straightforwardness of what you are actually going to do with the data. The intention becomes blurry. IMHO.
// the pattern// you will always provide a variable that will hold your data
var myVariables// keep making repetition of the looping block
for _, blabla := range blablas {
..state a search condition that might be used multiple times..
..append blabla to myVariables..
}
Imagine new engineers are coming to your repo and they have to search items in an array using that approach. The potential is high they will write redundant logics that actually do exist already because of their lack of knowledge about the repo besides the search conditions themselves are quite unorganized and decentralized.
By looking at that pain point. I started to think how can I solve this problem? That’s why this immature tiny library is out. This is how Fun-go’s filter function will come to rescue to save you from the pain:
Now, there will be no repetitive looping blocks that will blur your intention about what you are going to do with the data.
Everything looks clearer and more organized, various filter functions can be reused in another part of your code by simply calling them as you need using Higher-Order Function technique. Reusable means reducing redundancy.
You are now also able to build filtering pipeline like this:
If you want to find other examples related to map and reduce function. You can go to my Github repo: https://github.com/parinpan/fun-go
Benchmark
Tested on MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports) 2 GHz Intel Core i5 8 GB 1867 MHz LPDDR3 with 1,000,000 data.
Conclusion
Golang is fun. It’s agnostic to particular programming paradigms. Well, I can’t say it’s good enough to implement some of functional programming principles on it but still possible and brings us to a better approach of how we program.
Disclaimer
I’m not an expert in functional programming. Only a great fan of it! :)
Anyway, If you have any inquiry; you can contact me on: Linkedin or Twitter.
