Summary of Rob Pike's Why Go Is Successful a.k.a Simplicity Is Complicated

Summary of Rob Pike's Why Go Is Successful a.k.a Simplicity Is Complicated

If you are a software developer and you are not living under a rock, you must have already heard about Go and its successful application in various domains. This article is going to be the summary of Rob Pike's - Why Go is successful.


Common answers on What makes Go successful

You will get reasons like - speed of compilation, speed of execution, deployment, tools, libraries. But if you think about it, these are not even language features. Sometimes, true language features like interfaces and concurrency are cited. All of the above are important, but not the real answer.

What actually makes Go successful

Simplicity - Go is simple at least when compared to other established languages. Simplicity is complicated because it has many facets.

Language convergence trend

Most of the established languages actively borrow features from each other. They are converging into a single huge language. Why is it bad? - There is a principle called Linguistic Relativity which says that the structure of language influences the use. Now, in the programming world, we would want to think in different ways for a particular problem- for eg - Logic programming, Procedural, Functional, Object-Oriented, Concurrent. As a result, the language convergence trend is not only making existing language complex by adding more and more features but also is limiting our thinking in a finite way if it eventually gets structured into a single language.

Go is different. It doesn't blindly follow the language convergence trend

Go does not compete on features. Go language is fixed.
But at some point, you would need some features - Choose the right ones, not the ones that would just make Go bigger instead of different.
How to choose?
Design by consensus.
One way is to make use of the varied background of the developers and insist on agreement from each one of them. Robert, Ken, and Rob had vast experiences in different domains.

But any criteria to pick? - Readability

If a language has too many features, time is wasted in choosing which ones to use.
Also, at times in implementing, refining, and rethinking the chosen choice.
And later, "Why does the code works this way?"
The code is harder to understand just because it is using complex language. Features add complexity and hurt readability.
Readable code is more reliable.
A key tradeoff to consider, however: More fun to write or more maintainable.
Go aims for easier to work on and maintain.

Expressiveness

Balance expressiveness.
Too much expressive, is too much expense.
For eg: maps and filters can become expensive in terms of computer time instead of plain for loops.
Also, too much conciseness hurts readability. Got to find the right balance.
Be concise while remaining expressive.
Keep features orthogonal, while covering solution space and also interacting well with each other.
Simplicity can be expressive. Keep goals clear.

But is simplicity real?

Practically, to achieve simplicity, we need to hide the complexity.
Few simple things in Go: garbage collection, goroutines, constants, packages, interfaces
Each hides complexity behind a simple facade. We call it simplicity hiding complexity.

Some examples of simplicty hiding compelxity

Garbage Collection

Tough to implement - stack maps, copying stacks when need to grow, tracking all references, pausing it, and running it parallel with the mutator, etc.
But it's worth it. Yet so simple to use that the language specification mentions it in the introduction!
Code is simple because of it. The design does not need to include ownership. GC handles all your worries.

Goroutine

Three keystrokes (go keyword + space) to spin a sub-process (conceptually). As simple as it can be.
No need to consider:
stack size, return/completion status, a mechanism for management, ID, etc
Other languages may actually provide control over the above points. However, Go has a minimalist design. So easy on the outer side.
But again, simplicity is complicated. Implementation is complex.

Conclusion

Simplicity is complicated but the clarity is worth the fight.
Simplicity is hard - to design ,
Simplicity is complicated - to implement,
But, if done right,
Simplicity is easy - to use.