Get your *FREE Golang Cheat Sheet* - golangdojo.com/cheatsheet
@ezikhoyo Жыл бұрын
At 8:40 there is actually a mistake in your code. On the third panel you would need to do "go func(local int) { // code }(i)", and you forgot to pass i to the func, leaving it as "}()".
@ctts9946 Жыл бұрын
Eagle eyes
@touringtim73132 ай бұрын
I'm glad someone wrote that because I paused the video and had no idea how the third statement worked
@njengathegeek Жыл бұрын
The mistakes are well pointed out, thumbs up Wallace 👍
@GolangDojo Жыл бұрын
Glad you enjoyed it!
@ТимурМазитов-ч4о Жыл бұрын
8:19 forgot to pass i to the function call in the third example
@touringtim73132 ай бұрын
I'm glad someone wrote that because I paused the video and had no idea how the third statement worked
@Julzaa6 ай бұрын
Here are my own "7 Deadly Mistakes Beginner Go Developers Make", just for fun: 1. Don't discard errors using the blank identifier _ 2. Don't misuse goroutines and channels 3. Don't use nil maps or slices 4. Don't neglect testing 5. Don't ignore error values in tests 6. Don't misuse defer 7. Don't use global variables unnecessarily
@rui.craveiro Жыл бұрын
I think you made a mistake. You are stating that passing a struct by pointer can have worse performance than by value, and then you prove that returning a struct via pointer has worse performance than returning it by value. The problem with your approach is that you are using that benchmark to demonstrate, correctly, that returning by pointer is worse, as an extension of the concept of receiving by pointer vs by value. I am arguing that one is not an extension of the other and that receiving parameters is in fact a very different scenario from returning values, not an extension of the concept. And, because of that, proving that it is more expensive to return a struct by pointer doesn't prove at all that it is more expensive to receive a struct by pointer. Correct me if I'm wrong, but if the caller created and assigned the struct to a local variable and passed the address of that variable to a sub-function, that subfunction will receive a pointer to a variable on the stack, not on the heap. So, when I am receiving a struct by pointer, the memory where that pointer points to depends only on how the caller created that struct and not on the fact that we received it by pointer. This is different from returning by pointer, where the struct will necessarily need to be in the heap for that to be possible. Am I understanding this wrong?
@ForeverZer08 ай бұрын
This is the nuance that too many Go developers omit with the "passing by value in Go is faster" statement that is constantly repeated in the community. The concept isn't even unique to Go, the language design simply abstracts memory management away to make it less obvious. While the statement about passing by value might be generally good to tell someone coming from higher level languages and dipping their toe into pointers, memory management, and stack/heap allocations for the first time, it is bad advice and repeated without further explanation way too often, as if it is some rule of thumb that can safely be relied upon for most use cases, when that is anything by true.
@TehKarmalizer7 ай бұрын
Not necessarily. You don’t control where the allocation happens; the runtime does that for you. The fact is that value copies are pretty fast, but if you are copying many primitive values, that will be slower at some point than following a reference to some distant memory. Frankly, there are usually better reasons to pass a copy vs a pointer.
@caiqueribeiro21305 ай бұрын
From where I stand and with my knowledges about memory allocation, it's just like you said. The fixed problem here is to RETURN a pointer, because when you return an address to a variable from an inner context to an outer one, the variable has to be stored in the heap because it's not known anymore its lifecycle. When you pass the pointer as a parameter, it continues to be in the stack just because, according to de LIFO architecture, the variable is just going to an inner context and its lifecycle continues to be known. In case of structs and more complexes variables the question about heap x stack will be its size and other problems, not the fact it's being passed as a pointer or not.
@nichitatrifan9986Ай бұрын
The author unnecessarily confused beginners with his micro-benchmarking. It really depends what you are trying to do with the data. People can perform optimization for the heap access and as a result have better results, avoiding unnecessary copying of data multiple times.
@ssengalanto-vv6jo Жыл бұрын
testify library has ‘require’ package that does fatal on error
@luizhp7 ай бұрын
8:22 I think they fixed it on 1.22 package main import ( "fmt" "time" ) func example01() { s := []int{1, 2, 3} for _, i := range s { go func() { fmt.Println(i) }() } time.Sleep(time.Second) } func example02() { s := []int{1, 2, 3} for _, i := range s { localI := i go func() { fmt.Println(localI) }() } time.Sleep(time.Second) } func example03() { s := []int{1, 2, 3} for _, i := range s { go func(localI int) { fmt.Println(localI) }(i) } time.Sleep(time.Second) } func main() { fmt.Println("Example 01") example01() // 3 2 1 // fmt.Println("Press enter to proceed to next example...") // fmt.Scanln() fmt.Println("Example 02") example02() // 3 2 1 // fmt.Println("Press enter to proceed to next example...") // fmt.Scanln() fmt.Println("Example 03") example03() // 3 2 1 // fmt.Println("Press enter to exit...") // fmt.Scanln() }
@dineshr93 Жыл бұрын
At 8:32 , 3rd rightmost tile, shouldn't we require to pass the loop variable i to anonymous func's invoking braces }(i) ?
@Levelord92 Жыл бұрын
about fourth mistake, just replace assert with require and you'll get the same result
@mti2fw Жыл бұрын
"require" is from the native module?
@joao_silva679 Жыл бұрын
@@mti2fw It's from the testify package.
@MinhVo-jv5ts14 күн бұрын
At 1:42 The pointer is already pointing to the address of Ninja itself, so why are you assigning jPointer = returnNinjaByPointer again? That's why it is slower compared to pass-by-value in your example. In fact, we only need to operate on one address when we have already passed the value by pointer, and it only takes about 0.3309 ns/op.
@gy0624ww10 ай бұрын
the first mistake pass the paramter with (previous Ninja) and return with ¤t is faster?
@GoWithAndy-cp8tz5 ай бұрын
I think there is a little misunderstanding with pointers. Structures' names are pointers itself so making pointer to pointer will be slower as expected. Using pointers with structs is pointless.Cheers!
@Egzvorg3 ай бұрын
What? If that were true the struct's fields modified inside a function that received the struct as a value would change outside the function too.
@eastquack3342 Жыл бұрын
great vid Wallace; I used to forget passing the local var to the goroutine too
@codelinx Жыл бұрын
Love the format and clean layout for this go content
@PaulSmith-qr1iy Жыл бұрын
Priceless! Thanks so much
@omarcrosby10 ай бұрын
Yup, I've made pretty much all of them. Thanks for sharing.
@Ross96D9 ай бұрын
But you should compare having a function with a input pointer and returning a copy not a pointer.. or only make the example with returning a pointer VS a copy. Will only allocate to the heap if you are returning, no if you pass it as a param
@AbhishekSomaniTheGreat Жыл бұрын
At 8:38, the last example closure should have i passed in as argument. i.e. func main(){ s := []int{1,2,3} for _, i := range s { go func(localI int){ fmt.Println(localI) }(i) // this is required } time.Sleep(time.Second) }
@weyrdereveryday34787 ай бұрын
Another important argument for mistake 1: The stack and it's variables will stay longer in the processors L1 & L2 cache than heap-variables that have a costly long lookup-time in the RAM
@beofonemind2 ай бұрын
your ssl is toast
@toTheMuh5 ай бұрын
Regarding mistake 1: 17ns vs 43ns is not much of a difference efficiency wise, but what about memory consumption? If you keep passing values around wouldn't that lead to extensive memory usage? Especially in a microservice or serverless environment you want to avoid high memory consumption because otherwise you will need more instances and each instance of a service or function will cost you money.
@everyhandletaken15 күн бұрын
That was my thought as well
@arthurcoelho1224 Жыл бұрын
Great video! Does Golang Dojo have a discord channel or something? it would be nice!
@alexanderp4532 Жыл бұрын
2:48 extra benefit of stack: stack size is known at compile time, so the memory is allocated once per function call for all the variables, so it also doesn't require extra actions for allocating, because the stack is allocated every time you call a function. Vice versa, heap memory is allocated for every value separately, which is less efficient. 7:00 c'mon, man. Are you kidding? You took the simplest example to show that there is no difference between "idiomatic" way and third-party library. When your assert will require more comparison, you "idiomatic" way will become an unreadable garbage. One of the benefits of unit testing is being the closest to the documentation, so it should be readable. 10:23 that's your code in real tests, if you use "idiomatic" way)
@Simon-xi8tb7 ай бұрын
thanks for the sheet-sheet
@winfle7 ай бұрын
Interface values are store in a Heap, so be aware of it
@jamshidbekyuldoshev7542 Жыл бұрын
Which Go frameworks do you recommend to learn?
@sureshchaudhari44656 ай бұрын
how come i did not see your channel
@vitiok78 Жыл бұрын
I've made them all at some point)
@krist50 Жыл бұрын
i made 3 tip in this video
@nahueljj Жыл бұрын
i need subtitle in spanish xd
@parlor3115 Жыл бұрын
Well, the deadliest mistake a beginner can make is to pickup GO in the first place
@ElderSnake90 Жыл бұрын
Hello Rustacean
@parlor3115 Жыл бұрын
@@ElderSnake90 No, I just did some GO and realized how bad a language it is
@rui.craveiro Жыл бұрын
@@parlor3115 You likely didn't do enough to see the beauty in it. ;-) My first instinct about Go was that a language that doesn't have exceptions, classes or inheritance must not be from this century. But then I actually used the language a lot more and realised just how wrong my initial impressions were.
@parlor3115 Жыл бұрын
@@rui.craveiro If you're unable to migrate to the new version (which is always) You'd have to implement the same function 2+ times because your fav library have it's own custom string type / write some hack code / use source generators. There are no facility array / slice functions for common operations like map, reduce, filter, includes, ... . The module system is abhorrent being limited to a single module per directory. Unnecessary style guidelines enforced by the compiler (not being able to write "else" on a new line). The only advantage GO brings is that the runtime is shipped along with the binary and I think if MS manages to achieve the same thing with C# or if a subset of Rust is created without all the added complexity, then GO will definitely go out of scope.
@rui.craveiro Жыл бұрын
@@parlor3115 I am aware of all the facts you point out and my opinion is unchanged.
@antoniothomacelli2 ай бұрын
Thief Golang Dojo sell course and after remove platform with our money!