Good video, but there is an essential detail about the defer statement that you omitted which can be a really awkward gotchya if you’re not aware of it. And that is a defer creates a closure over local state. Your defer statement must make sure that any state that it interacts with is fully present at the time of the defer statement. Eg, let’s say the first thing inside of a func is a var declaration of an uninitiatialised variable. Next there is a defer that interacts somehow with this state. After the defer there is some logic that updates this state. If you think that when the defer actually runs it will see the updated version of that state, you will be surprised to learn that the version of that state the defer sees is the uninitialised version. This was a shock to me when I first discovered it and took me quite a while to realise what was happening. This occurs because the defer is working on the closure version of the state and hence only sees the uninitialised version. Hope this helps anyone to not fall into this subtle trap.
This not always true, it depends on the defer declaration Test it with: func work() { var v string defer func() { fmt.Println("V in func's defer", v) }() v = "asd" fmt.Println("V in func", v) } Outputs: V in func: asd V in func's defer: asd BUT: func work() { var v string defer fmt.Println("V in func's defer", v) v = "asd" fmt.Println("V in func", v) } Will indeed output: V in func: asd V in func's defer:
Good video, but there is an essential detail about the defer statement that you omitted which can be a really awkward gotchya if you’re not aware of it. And that is a defer creates a closure over local state. Your defer statement must make sure that any state that it interacts with is fully present at the time of the defer statement. Eg, let’s say the first thing inside of a func is a var declaration of an uninitiatialised variable. Next there is a defer that interacts somehow with this state. After the defer there is some logic that updates this state. If you think that when the defer actually runs it will see the updated version of that state, you will be surprised to learn that the version of that state the defer sees is the uninitialised version. This was a shock to me when I first discovered it and took me quite a while to realise what was happening. This occurs because the defer is working on the closure version of the state and hence only sees the uninitialised version. Hope this helps anyone to not fall into this subtle trap.
This not always true, it depends on the defer declaration
Test it with:
func work() {
var v string
defer func() {
fmt.Println("V in func's defer", v)
}()
v = "asd"
fmt.Println("V in func", v)
}
Outputs:
V in func: asd
V in func's defer: asd
BUT:
func work() {
var v string
defer fmt.Println("V in func's defer", v)
v = "asd"
fmt.Println("V in func", v)
}
Will indeed output:
V in func: asd
V in func's defer:
@@rumenneshev9433 ok I’m not going to dispute your case, but my point still stands. Beware of how you do defer
@@dawnrazor Yes, not meant to argue, just to note that there's a way to work around this defer "problem". Still - Beware of how you do defer
Great videos, you deserve more views, subscribed!
Wow, thank you so much 🥺
great video. can you name the font please?
Thank you! I am using the Monaspace font :)
@@FloWoelki great. thanks for the reply.
noticed you are using zed, which theme is that?
It's the GitHub theme :)
which ide do you use
I am using Zed at the moment :) I've also made a quick video about Zed, if you want to check it out.
loved it