Help needed understanding receivers in Go

I am in the middle of taking a Go online course. I was comprehending pretty well until I hit a brick wall on the idea of a receiver in the methods discussion. Can someone attempt an explanation of how they work and how they are used practically in programming? This is my first major dive into programming except for some Python and a brief intro to basic in the stone age of my high school days!

Method receivers define what struct type a method is associated with and how that relationship should be treated. There are two types of receivers in Go, value and pointer receivers. Value receivers get a copy of your structs data without the ability to modify it, and pointer receivers allow you access to the struct directly.

More on methods, the deeper details on Tour of Go:


In a high level,

go is a functional programming language, yet it has features of object oriented programming (OOP).
If you know OOPs, you know that there are classes and objects with their own variables and methods

This is just like that. Consider your struct as an object. The method works the same way. Receiver is the object.
And don’t take what I said practically. Just a theory to understand if you have prior OOP knowledge.

And just like @CurtGreen said, there can be value and pointer receivers.
You couldn’t get a better definition :slight_smile:

Its not.

Some may say so, but even though functions can be returned and taken as a parameter, doing so feels wrong and clumsy.

I rarely see code that really uses functional paradigms or especially higher order functions.

Even the most simple HOFs are barely useful in go, especially as the lack of generics or templates makes you repeat them a lot just with different type signatures.

Just consider id or const from the Haskell world:

id :: a -> a
id x = x

const :: b -> a -> b
const b = \_ -> b -- real haskellers would implement it differently, its only
  -- this way to make it easier comparable to the following go code.

In go it would be like this:

func id(x int) int { return x } // this is actually still readable, but only for
  // int, go on and repeat for all the other types without using interface{}, as
  // this would make things worse…

func const(a int) func(b int)int {
  return func(b int) int { return a }

Now go on and try even more useful HOFs as a map, reduce…

PS: Also a functional language would put more effort into TCO and not limit the call stack artificially…


Thanks for the detailed explanation. Go cannot be treated as a function language or an OOP language but has most of the capabilities and features of both, in it.

I thought we were terming it as functional since its closer to that. I just came to know of the term “Multi paradigm programming language”, which is what Go is.


The Wikipedia article on Go says it is

Multi-paradigm: concurrent, functional, object-oriented, procedural

Considering that list, I think it works better to read it backwards. :laughing:

Languages that were around in the 1960s were mostly procedural languages, including Fortran, Algol, Basic, Pascal, and C. Pascal and C are both based on Algol, and Go is based on those.

I think of Go as a procedural language with some modern features from object-oriented programming, functional programming, and concurrent programming.


@jayts Haha. Thanks for the rescue :wink:

Great! :smile:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.