Rakyll.org Website Review

Articles mostly about Go and what I am currently working on. Conventions, best practices, little known practical tips. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License It is real struggle to work with a new language, especially if the type doesn’t resemble what you have previously seen. I have been there with Go and lost my interest in the language when it first came out due to the reason I was pretending it is something I already knew. Go is considered as an object-oriented language even though it lacks type hierarchy. It has an unconventional type system. It is expected to do the things differently in this language given the traditional paradigms are not always going to help the Go users. This article In Go, program flow and behavior are not tightly coupled to the abstractions. You don’t start programming by thinking about the More recently Rob Pike shared his thoughts on the separation of data and behavior: > … the more important idea is the separation of concept: data and > behavior are two distinct concepts in Go, not conflated into a Go has a strong emphasis on the data model. Structs (which are aggregate types) provide a light-weight way to represent data. The lack of type hierarchy helps structs to keep being thin, structs never represent the layers and layers of inherited behavior but only the data fields. This makes them closer to the data structures they represent rather than the behavior they are additionally providing. Code reuse is not provided by type hierarchy but via composition. Language ecosystems with clas*ical inheritance is often suffering from excessive level of indirection and prema*ure abstractions based on inheritance which later makes the code complicated and unmaintainable. Instead of providing type hierarchy, Go allows composition and dispatching of the methods via interfaces. The language allows embedding and most people as*ume the language has some limited support for sub-clas*ing types – this is not true.