Golang, a static language apt for large codebases

Carlos Lenz
Jul 25, 2017 · 3 min read

The bigger the interface, the weaker the abstraction. — Rob Pike

When all we had was C, programs were supposed to be small (following the unix tradition of small tools glued with pipes) and the language didn’t make much effort to help you beyond that. So codebases only scaled through internal standards, different from one another, on top of the language and not enforced but manually. Most of the functionality was reimplemented many times, since the standard library is limited in most areas. Compilation time was not stellar due to the #include mechanism.

Then came C++, which took the latest code organization technique (classes) and forced it into C’s runtime. This language is a tribute to how much humanity can work on something it cherishes! Even after all those years there are attempts to make it better. It’s questionable if both parts fit well together. Some requirements for large codebases are still not integrated (e.g, style guide), and the standard library scope is not much larger than C’s. Compilation time got significantly worse than C due to templates.

Java tried to get rid of C heritage in many ways (except for the syntax) and tried to mimic Smalltalk’s OOP to a larger extent. So it provides a large standard library with much more ready to use solutions (compare that to C!). But smalltalk’s design has one serious implication for static languages: Interfaces are huge. Smalltalk does not have interfaces because it works through duck typing. But in a static language, functions must declare parameter and return types and restricting those to concrete classes hard-codes the codebase too much. So Java added interfaces that almost mirrored the concrete classes’ API. This means they are huge and the adding a new implementation requires significant effort. So they added abstract classes, which meant using inheritance to share implementation. Code style is not consistent across projects either. Compilation time is not fantastic, because the runtime is large and the JIT requires some warm-up time.

Go re-imagines Smalltalk influence and this is one of its most distinct design choices. It does not have static fields and methods and inheritance is gone, replaced by composition, which is much more in line with C. Visibility options (public, private, friend and the variations) are limited and implicit rather than declared (public fields and methods start with an uppercase letter, the rest is package-friendly). Code formatting and style are recognized up-front and increasingly standardized and automated. The standard library is larger than C++ but smaller that Java, so there is less cruft and deprecated functionality around. This was designed into the language, not afterwards. The community recognizes this and tries to adopt the same principles. Compilation time was without parallel before the compiler was rewritten, but it is still fast and every release since then has tried to improve it.

The adage in the beginning can be easily appreciated when comparing Go’s Reader / Writer / Closer with Java’s InputStream / OutputStream / Reader / Writer. Being a language that has adopted the best ideas from several others (e.g, CSP concurrency), this principle might be the biggest contribution go offers to programming language design: define small interfaces whenever possible!

Carlos Lenz

Written by

Brazilian Backend Developer that kicks with the Frontend leg too. http://sudecke.com/lenz

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade