Made withGinClip

Beginners Should Think Differently When Writing Golang

A

Anthony GG

Creator on the Gin channel

Watch on YouTube ↗

213K viewsSep 4, 202311:35 runtime

Understand the fundamental shift in thinking required for writing effective Golang code, especially if you come from an object-oriented background like Python, C#, or JavaScript. This video breaks down why Go is fundamentally data-oriented, not object-oriented. Learn to view Go…

Chapters

#gin#clip#backend

The Core Mindset Shift

To write effective Go, you must shift from an object-oriented (OOP) mindset to a data-oriented one. Instead of thinking in terms of classes, objects, and inheritance, think in terms of simple data and the functions that operate on it.

Important
In Go, everything is just data. Your primary job is to define how this data is structured and how it will be manipulated.

Structs as Data Containers

In Go, a struct is the primary way to group data together. It is not a class.

A struct is a composite data type that groups together zero or more named fields.
It's best viewed as a simple data container or an envelope holding related fields.

type Book struct {
    Title    string
    Author   string
    NumPages int
    IsSaved  bool
    SavedAt  time.Time
}

Note
Resist the urge to see Book as an "object." It's just a named collection of fields. You can only do two things with it: read from it or write to it.

Interacting with Data via Functions

All manipulations and operations on a struct's data are performed using functions.

A method in Go is simply syntactic sugar for a function that accepts the struct as an argument.

// A regular function operating on a Book pointer
func SaveBook(b *Book) { /* ... */ }

// A method with a pointer receiver (syntactic sugar for the above)
func (b *Book) Save() { /* ... */ }

Value vs. Pointer Receivers

Understanding the difference between value and pointer receivers is crucial for managing state.

Value Receiver (func (b Book) Method())
- Operates on a copy of the struct.
- Any modifications made inside the method are applied to the copy and will be lost when the method returns.
- Use for read-only operations where you don't need to change the original struct.
Pointer Receiver (func (b *Book) Method())
- Operates on the original struct via a pointer (its memory address).
- Modifications made inside the method will persist because you are changing the original data.
- Always use a pointer receiver when you need to modify the struct's state.

Tip
The object-like syntax book.Save() can be misleading. Mentally translating it to Save(&book) helps reinforce that it's just a function call operating on your data.

The "Go" Way: Data + Functions

The fundamental model of Go programming is simplicity itself:

Define your data using structs.
Define functions (or methods) to read from and write to that data.

Changing Your Mindset for Go

If you come from other languages like JavaScript or Python or C++ or C# or whatever and you're coming to Go, a lot of things can be very complicated or confusing. And this has nothing to do with your skill level; this has to do with the different way of the approach you need to take if you want to be a Go programmer.

And what do I mean with a different approach? You need to start thinking... you need to start thinking in the way of data. Everything is just data, right? And of course, all these other languages like JavaScript... they are great, amazing. Python, amazing languages. But they have a different way of thinking. And if you need to jump into Go, then you're gonna basically try to utilize what you have learned in these other languages, which is completely normal, but that's going to produce not a correct code or not the correct approach of doing things. And this is going to be a video that is going to clarify a little bit how to change your mindset on how to write Go code. Back to the basics, keep it very simple, right? So let's get started into this.

Structs: Data Containers, Not Classes

So, the reason why I'm doing this video, guys, by the way, is because I'm making a lot of Go videos and I still see people ask me, "Yeah, but this sounds a little bit confusing for me coming from from Python," or, "Yeah, and is this a class? Do I need to use this?" and all that stuff. And I want to basically debunk all that shenanigans, right?

So first of all, let's make something very simple. Let's do the classic stuff. Let's make a type of Book right? And this book is going to be a structure. Okay? And let's give it some fields. We're gonna say title string. Let's keep it very simple, right? Title, maybe an author or something is also going to be a string. And then we're going to say numPages... this is just some decoration here, right? And I'm gonna say for example isSaved or something is going to be a boolean. And then we're gonna have a savedAt it's going to be a time.Time, right? Something like that. Okay, cool.

Thinking of Structs as Encapsulated Data

So, a lot of people think of these structures as objects or classes. Which, if you think about it as objects, is not such a bad thing, but thinking about them as classes is completely the wrong way of thinking.

So you need to see a structure as just a collection... is not the right word. As an envelope, as a group... is maybe also not the correct word, but like a wrap around just data.

Simple data: a string, an integer, a bool. And this is basically encapsulated into a global name, Book. Right? And if you want to access a title or another page, you just gonna call the title. Very simple, right?

But that's the thing, right? It's very simple, but it still directly reflects on how we use classes, because Book is going to be this entity which could have some properties, right? But in Go, this Book is just a simple data structure holding fields, holding member fields.

The Two Fundamental Operations: Read and Write

And the only way... there are actually two things we can do with this Book, right? There is only two things we can do. It's very simple. Two things we can do with this structure. And that's basically, one, let's do a comment here. One is going to be, we're gonna read data from this book. And then we're gonna write data into this book. That's the only thing we can do. Nothing more and nothing less.

Functions vs. Method Receivers

And how do we read and how do we write data from it? Well, if we wanna do stuff with Book, we can only do that by using functions. It's as simple as that. Only functions.

So for example, if I want to save this book, and I'm going to explicitly write this a little bit differently, and the only reason why I'm doing this is so you can change your mindset a little bit. So let's say we want to save this book. So we're going to say a function, we're going to call this SaveBook, right? And if you want to save a book, what do we need? We need the book, right? So we're going to say book which is going to be a Book, right? That is simple. And I'm going to say book.isSaved is going to be true, right? And I'm going to say book.savedAt is going to be a time.now. It's that easy.

But I already see your eyeballs, your eyebrows frown. Because, first of all, why are we writing this like this simple function here, like just a plain function? Go has something like method receivers and all that stuff. That's true. But if we write this like the Go way, because it's just syntactic sugar what I'm gonna do right now, is just syntactic sugar that is allowed by the compiler, is to do something like a book, Book, SaveBook. Right? And then we're gonna copy these two fields here, right? We're gonna paste them in. And now we have these two functions are exactly the same.

But if you look at this, what we see is that this looks a lot like some kind of object-oriented approach where we have this Book and we have a method attached to that book, and we're gonna do stuff with that Book. And that's where the confusion comes in, in my opinion. That's why a lot of people are confused here.

So let's think of... let's delete this function. And let's keep this the old school C-way function here, right?

The Pitfall of Passing by Value

Now the magic is gone, right? The wizardry and witchcraft is completely disappeared from the screen. Because right now we have a simple function like we know that in a lot of other languages. And we have just a Book and we're gonna modify the state of the book. But! But, but... what do we know here? We know that this Book here is a function argument. And what do we know? That this Book is going to get copied into the stack of this function, right?

It's going to get copied into the stack the same way as with this function, which are again, these two functions are completely the same. This book... this is just a function, right, guys? This is just a function. It's a syntactic sugar that is the same as this. This Book is going to get copied into the stack of this function, which means that we are going to modify a copy of the book, which also means, programming 101, that at the end, we're gonna burn the book, right? We're gonna burn the book. The stack is going to get cleaned up and everything we did is going to waste because we have a copy.

Using Pointers to Modify State

So if we want to modify state, what we need to do is... we need to, I'm gonna delete this thing again... what we need to do is we need to have a pointer to this book. So we can modify... we don't modify the copy, we modify the memory of that book so it's reflected everywhere we have a reference to that book.

So now the stack is going to get cleaned up, but this is a pointer, so the values we changed are going to be persisted, right? So now this looks a little bit different already, right? Because now it's very simple to understand. It's just a function, takes in a book, okay, it's a pointer to the book, and we set book.isSaved true, savedAt is... GG, well played, the game's over. Let's close this pull request, right?

But in Go, like I said before, they gave us the opportunity to make this a little bit less tedious, make it a little bit more, maybe convenient. And that's by having a function receiver or a method receiver, whatever you guys wanna call that. And most of the time you're gonna see b *Book, right? But let's keep it simple. Let's make this reflect the function we already have. So we're going to say book and now we need to say SaveBook, right? And then we're gonna do... we're gonna copy these things here and paste them, right?

So now we have two equal functions here again, right? We have this book which now instead of a copy of the book, we're gonna have the actual pointer of this book. And now we can modify the data, which is exactly the same as this function here. But if you come from another language and you see a function like this, you're directly going to be interconnected with the object-oriented approach paradigm because it looks the same, right? It looks kind of the same. But if you take a look at this, it's a little bit different, although it's gonna do the exact same thing.

That's how you need to see this. How this is how you need to... I don't know the correct word, but this is how you need to perceive Go programming. Right? It's just data. There is no object. It's just a structure that holds this data. And the only thing you're gonna do is you're gonna read that data or you're gonna manipulate that data. And if you manipulate that data, or even read, the only way you can do that is by functions. Of course, if you want to read, you can access the object directly, of course. But if you want to modify stuff or you want to operate, you want to do some modifications, operations on that structure, you're going to use procedures, you're going to use functions.

Conclusion: Go is About Data and Functions

So Go is all about... it's only about structures, data, and functions. That's the only thing you need to know. And if you use that approach a little bit more, if you use that narrative, that thinking a little bit more, it's going to get more clear for you... or maybe even more confusing, who knows, right?

So, I know this sounds a little bit weird, this video, but it's a very important one because I understand completely that you are confused sometimes. And I hope this video has completely enlightened you in this way. So if you like this video, consider subscribing, give me a thumbs up, and leave some questions in the comments. Jump into my Discord community, and I'm looking forward to see you in the next live stream or video. Take care.