Understanding of Go Programming Philosophy


Due to recent project requirements, I need to write Go code. As someone who has been using TypeScript and Kotlin, both languages that contain a lot of syntactic sugar, I found it difficult to adapt to Go at first. I started off by complaining about the various shortcomings of Go and eagerly awaited Go2, which would include generics. However, as I continued to use it, I gradually understood the original intentions behind the various designs in Go.

  • By returning errors explicitly.

    Force developers to think about the cause of this error and whether it should be handled.

  • Strictly distinguish between pointer types and value types.

    Forces developers to think about choosing types and the risks involved.

  • Better source code reading experience.

    Object-oriented languages like Java have a tight hierarchy of types, which often requires developers to navigate through layers of code to understand the implementation. The root cause is actually the tight coupling of inheritance, which developers heavily rely on.

    Go almost forces the use of composition over inheritance, ensuring code simplicity as much as possible.

  • No generics are provided to prevent the creation of code that is easy to write but difficult to read.

    A piece of code is written only once but read countless times. A generic function undoubtedly raises the barrier to understanding the source code.

    Generic functions are often called by many unrelated pieces of code. However, once the requirements of one of these calls change, it is necessary to re-understand the generic function and rewrite a new one, which may lead to even more severe code duplication.

  • The high level of restraint in Go allows developers to maintain the lowest cognitive burden while developing.