Appropriate Programming Paradigm for Go

Henry Adi Sumarto

unread,

Oct 9, 2015, 1:06:16 PM10/9/15

to golang-nuts

Hi,

I have been wondering. Given Go's feature set, what would be the appropriate programming paradigm for Go? I am sure that the designers of Go must have certain use cases in their minds when they design the language.

At a glance, it seems that Go is designed to be a major update to C. It looks like C with a better support for modularity, Unicode, memory management, and concurrency with a major overhaul to the standard library to reflect the modern needs. If that is the case, then data-centric, procedural approach ala C should be the recommended approach to designing Go programs.

On the other hand, Go's support for method also indicate that Go can support object oriented programming. However, Go's support for OO seems half-baked. The struct's private methods are still visible to others in the same package. They look like C++ friend classes. Go's inheritance (via composition) is either data-only or function-signature-only inheritance. It is not a true inheritance where both the data and the behavior are inherited. The list goes on. Although you can implement a true OO in Go if you really insist, the amount of work that goes into it seems unnecessary especially if the language isn't really designed for it in the first place.

So, when designing Go programs, should we model objects as in the case of OO or should we start with data modelling ala C language? Earlier I started out with OO approach for a pet project and later on I am reeling with pain for trying to model objects. I wonder whether I should have started out with data-centric procedural approach instead.

Thanks.

Henry

Shawn Milochik

unread,

Oct 9, 2015, 1:26:19 PM10/9/15

to golan...@googlegroups.com

I highly recommend reading this.

http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

It explains why a lot of the design decisions were made. As has been stated by various people, including those on the Go team, the language is designed to let you build anything -- even if that means first building the pieces you need to build those things.

Nodir Turakulov

unread,

Oct 9, 2015, 5:00:32 PM10/9/15

to Henry Adi Sumarto, golang-nuts

Let me quote Effective Go:

Go is a new language. Although it borrows ideas from existing languages, it has unusual properties that make effective Go programs different in character from programs written in its relatives. A straightforward translation of a C++ or Java program into Go is unlikely to produce a satisfactory result—Java programs are written in Java, not Go. On the other hand, thinking about the problem from a Go perspective could produce a successful but quite different program. In other words, to write Go well, it's important to understand its properties and idioms. It's also important to know the established conventions for programming in Go, such as naming, formatting, program construction, and so on, so that programs you write will be easy for other Go programmers to understand.

I recommend reading the entire document.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Benjamin Measures

unread,

Oct 9, 2015, 7:24:12 PM10/9/15

to golang-nuts

On Friday, 9 October 2015 18:06:16 UTC+1, Henry Adi Sumarto wrote:

Go's inheritance (via composition)

Inheritance is not composition, and neither is composition inheritance.

Although you can implement a true OO in Go

Class-based inheritance OO is not the "one true way".

In fact, it is recommended that we should favor composition over inheritance [1]. When queried about what the designer of Java would change about the language he famously answered, "I'd leave out classes." [2]

Since clarity and orthogonality are core to Go [3], it does does away with inheritance and subclassing for composition and subtyping.

Trying to fight the language on this has the outcomes of either doctored strange Go or: how I learned to stop worrying about inheritance and love the composition.

[1] http://efectivejava.blogspot.co.uk/2013/07/item-16-favor-composition-ovr.html

[2] http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html

[3] http://web.stanford.edu/class/ee380/Abstracts/100428-pike-stanford.pdf

Message has been deleted

Egon

unread,

Oct 10, 2015, 9:47:55 AM10/10/15

to golang-nuts

On Friday, 9 October 2015 20:06:16 UTC+3, Henry Adi Sumarto wrote:

Hi,

I have been wondering. Given Go's feature set, what would be the appropriate programming paradigm for Go? I am sure that the designers of Go must have certain use cases in their minds when they design the language.

At a glance, it seems that Go is designed to be a major update to C. It looks like C with a better support for modularity, Unicode, memory management, and concurrency with a major overhaul to the standard library to reflect the modern needs. If that is the case, then data-centric, procedural approach ala C should be the recommended approach to designing Go programs.

On the other hand, Go's support for method also indicate that Go can support object oriented programming. However, Go's support for OO seems half-baked.

The struct's private methods are still visible to others in the same package. They look like C++ friend classes. Go's inheritance (via composition) is either data-only or function-signature-only inheritance. It is not a true inheritance where both the data and the behavior are inherited. The list goes on. Although you can implement a true OO in Go if you really insist, the amount of work that goes into it seems unnecessary especially if the language isn't really designed for it in the first place.

So, when designing Go programs, should we model objects as in the case of OO or should we start with data modelling ala C language?

That question is easy... yes.

The point is that, you choose the paradigm that suits your situation. There is no single paradigm that works for all cases.

As for writing code -- the best mindset I have found is "what provides the most value for the end-user? -> write it as a package, class, function or even constraint and trying to keep the clarity of the value".

In some cases functional code allows to express data transformations.

Object Oriented helps to avoid impedance mismatch between the end-user and code.

Data-driven allows nice data manipulation and keeps code performant.

Dataflow allows nicely to manipulate data-processing.

Logic and constraint programming allows to figure out solutions to a specific criteria