Golang Tutorial #20 - Structs and Custom Types

The golang tutorial covers structs in go. Golang implements structs as it's own custom types. They are meant to be an alternative to classes from object oriented languages.

◾◾◾◾◾
💻 Enroll in The Fundamentals of Programming w/ Python

◾◾◾◾◾◾

⚡ Please leave a LIKE and SUBSCRIBE for more content! ⚡

⭐ Tags ⭐
- Tech With Tim
- Golang Structs
- Structs Golang
- Custom Types Golang
- Structs in Golang
- Types Golang

⭐ Hashtags ⭐
#Golang #GO

[Ciano]

@2:10 "Always we start with a capital letter" - Yes, but only if you want your struct to be public. If you want your struct to be private, you should name you struct with a lowercase letter to start.

[animedeathfire]

I glad someone took the effort to make an informative video on structs. Thank you.

[arcqq]

This is the first video I've watched from your channel and you're already my favorite

[brutalbutler]

i hope you still make Go videos once this tutorial series is over. It is an amazing language with a bright future.

[patrykolszewski]

Hi Tim, I took one course and now watching you to compliment knowledge about go. I would say your tutorial is much clearer but lacking goroutines/concurrency topic ;) anyway great job looking forward some time in future to watch your concurrency in go video, thanks

[emeraldls]

Tech with Tim & Net ninja are my Best channels to learn anything

[manmanollet]

Men!... you have just answered tons of questions in my mind bout types....
Great job explaining with actual coding... you deserve a million subs. ; )

[RichSad]

Thanks for this. Pace is just fine as I've been a C/C++ and various assembly language developer for decades. What I am not, and maybe it's me being thick, is how this DIFFERS from C/C++. So far I see a lot of the same constructs, perhaps without all of C++ permutations. I have a feeling the difference is in memory management and coroutines to achieve multitasking . But please make a point when you are describing a concept that breaks free from C/C++. Thanks. Keep it up.

[kenrod]

Thanks for the series Tim, you do excellent work.

In this instance, the explanation of pointers would be better served by using a word other than "Point" for the struct. "Location" or "Coordinate" are phonetically distinct enough to help the learner to separate the concept of "Point" and "pointer". This is especially true for non-native English speakers and the visually impaired.

I encounter this a fair bit in programming tutorials. It's difficult to juggle teaching difficult concepts while being mindful of this. Again, great series, Tim.

[lilrose]

Thanks, man your videos are amazing, keep doing!

[nayalashmohammad]

Thanks for making these GoLang videos and please continue. Also if you can make a tutorial where you make a Golang AUTH/OAUTH REST API from scratch that would be great!

[ToddsDiscGolf]

11:10 what if you get rid of the ampersand but leave the asterisk?

[nenadilic]

This is my two cents about passing the pointer to the function instead of the value, when we want to change the value of that variable. In this case it was the variable p1, which is of type Point. Instead of explaining why p1 is not changed by the function changeX by saying that this (and any) function makes its own copy of p1 (which technically is true), I found it easy to understand it this way:

Every function has its own variables (input, local and output), and the moment it executes itself, they are all gone, vanished, erased. They all have a scope that is just within that function. If you don't return anything to the function 'main', those variables are not defined if you try to use them outside that specific function (within the body of the function 'main').

Exactly the same applies to the blocks of codes such as 'if', 'if-else' and 'for-loops'. Whatever is declared and modified within them is vanished and undefined after that block of code.

That is why you have to declare the variables that you want to modify in the 'if' statement or the 'for-loop' BEFORE that block of code, in order to keep them.

The same goes for functions: you have to declare the input variables within the function 'main' and store some values in them BEFORE you call a function (and then again in that function's definition line, not necessarily with the same name, because the original input values are copied into local variables). What about the output variables? You declare them outside the function (within the function 'main') BEFORE you call the function (or at the same time, using the ':='), then declare them inside the function (not necessarily with the same name, any local name will do), unless they are the very input variables, in which case they are already declared immediately after the function's name, then do something to get their values and then you have to return them to the function 'main' using the 'return' statement.

So, perhaps for some people it is cool to use the pointers and all this fancy syntax, but if you just add: 'Point' before the curly braces in the definition of the function changeX (as the return type) and, instead of 'fmt.Println(pt)', you write: 'return pt', then you can call this function like this: p1 = changeX(p1) --- you are passing the current VALUE of p1 to the function, which changes its x field to 100 and returns this changed value of p1 to the function 'main' at the statement it is called from.

Then, you can either print it from the function 'main', or do whatever you want to do with it, but you actually did change the value of x in the p1 Point by passing the VALUE of p1 to the function changeX. The pointer thing is not necessary and it makes things confusing when they are not. To me, it boils down to fanciness of some programmers.
:)

Then again, it may be true (I am not completely sure about this) that you can spare some memory space by passing a pointer, because you wouldn't temporarily copy the entire struct by the function (changeX, in this example), but would only make a single temporary local variable for the pointer for that struct. As I said, I don't know if this is true, and even if it is, with today's memory, why bother saving a tiny spot of space, and even those extra copies that a function itself makes last only until that function finishes its work.

[drdand]

Tim, how do I get access to all your Goland Videos? Thanks.

[rthu]

It's not just struct, I believe it doesn't require dereference for any type used with a pointer

[sushantagawane]

Good Going brother, keep it up. Please bring videos on creating Rest API using golang. Thanks!!!

[nibrasmuhammed]

which font are you using in visual studiocode?

[cd-stephen]

thank you - your explanations are excellent - new sub

[white-cube-ir]

Golang now have generics. Can you make a tutorial video for that?

[numbr]

Two comments: Scoping of variables / structures / functions /methods / etc in Go depends on is the first letter upper case or lower case. lower case names are NOT visible outside of the package that defines them.

Coming from a C background ( not C++, just C ) pointers are used "everywhere" and are somewhat "dangerous" in C, for reasons I will not go into here.Given Go is a strongly typed language, it is nearly impossible to pass the wrong type of any argument into a Go function, as it won't compile. Dangerous pointer mistakes that are all too easy to make, or "abuse" for clever purposes cannot be exploited in Go. That is a huge improvement in Go over C.

The one core concept missed in this lesson and a few back: Go and C are both "pass by value" languages. That means anything passed as a parameter into a function argument is the value of the variable passed. That is why it is not possible to modify any values in Point in a function; a copy of the values of Point are passed. This key point here is when you pass something by reference using &pt, that address is passed into the function BY VALUE, which means you CAN now changes x / y in Point as you passed by reference the address location of pt. Not that you can, but this also means you cannot change the value of the &pt passed into the function, as that address is passed by value.

C makes a distinction between the . and -> operators when used with structure pointers. To use . you MUST do (*pt).x = 7, for example; pt->x = 7 is identical. The -> operator is syntactic sugar in C, and makes dereferencing structure members easier. I never really understood why you HAD to use (*pt).x, as the compiler clearly knows pt is a pointer from the function signature. I think it goes back to K&R C compatibility.

In Go, -> and <- are channel operators, so those have been removed from pointer dereferencing from Go, and are strictly used for channel operations.