When I started my career as a developer, it was about last year of my graduation. At that time, I was like a Java fanboy. I fell in love with Java while studying it. Honestly, It felt very natural as a programming language. (and don’t get me wrong – I still really like Java) When I started working on real projects in my early days of the career, I realised that there is much to learn about programming languages & their semantics. I worked with many smart people and introduced to a whole bunch of new techniques, patterns, libraries and tools to build software in the fast and efficient way. It was a good and overall very enjoyable learning experience but I also passed through some of the issues about the current state of programming.
The Problem with Black box Abstraction
When I started building apps, I was introduced to some popular libraries that are recommended to use for general stuff like networking, databases and image decoding etc. I am very curious and so I always tried to find out how some big libraries works under the hood. I tried to look at their GitHub repositories and navigate to some code and tried to understand how it does some XYZ things. It was very beginning of my career and I always failed to fully understand how they do. So, I asked to some of my colleagues and some of them replied:
“Who cares how it does something? It always works”
“You just need to learn about how to to use them. Don’t worry about inner details”
The library is just someone other’s code that provides an abstraction on certain things to make our life easy. But the point is why it is harder to read code than to write it? Why sometimes it becomes difficult for a beginner to look at someone other’s code and reason about it? Is it because the code is written as that one may get confused. or is it because one may not know certain design patterns used in that library? or is it because the programming language itself can do many things in many ways that one doesn’t know about them?
Almost every beginner and most end programmers tend to use libraries and frameworks without understanding how it does something under the hood. They see them as a black box. The black box that does certain things for them and make their life easier.
This is a big problem. Most of the times, it takes more time to understand someone’s code than writing it by yourself. This is why code reviews are taken more around code quality rather than software architecture or performance. Readability is the only most important thing considered while taking code reviews.
I don’t think that libraries and frameworks should provide the abstraction in such way that hides the details of the underlying system. Rather, they should provide the abstraction in a way that people can actually understand the underlying system. Too much abstraction becomes a barrier for most people, especially beginners to actually understand what the system does. It makes them think more about doing things rather than going deep and understanding things. That’s not a good thing. We want people to actually understand the details of stuff under the hood, not to learn the ways of using things. Anyway, this is my opinion and not everyone would agree on it.
For the last couple of months, I have tried many new programming languages. I tried Dart and Kotlin. I looked at Rust and Swift. I like them. They all are feature rich. But they all forces you to think the same and believes that it is the standard paradigm for building good software.
Then, I tried Go. It took me less than two hours to learn the basics of Go. The language is simple and syntax is very much concise. The most important thing I liked about Go is that it has a minimal set of what called ‘features’. For an example, Look at the way of handling errors. At first, it looks very different from a Java background. But when you try it, you will realise that this is the way I should handle the errors. Go is a perfect blend of notions that makes the language very easy for learning and programs more readable for any level of programmer. The way interfaces are used feels very natural. There are no classes and so there is no type hierarchy – the hierarchy that can be broken by subtle changes after decisions. There are no generics. Sometimes I miss them. But when I think as a beginner, I think it is nice not to have them.
The most important thing in Go is that it solves above stated problem. Any beginner can easily read through the libraries and know how it works under the hood. It is very easy to read other people’s Go code and it always takes less amount of time than other languages.
With the current state of IDEs and tools, I feel very productive in Java. But as the second language of choice, I will surely go with Go. :=)