I've been writing Go for a month, but have 5 years in industry. These are all pretty basic concepts in Go. Also don't use goto. It destroys control flow and there are other ways to do what it enables. If you look at C, goto exists, but you really only see its use when taking emergency recovery actions like in the Linux kernel.
I agree with you, but it's definitely good to know the concepts. Sure, they do destroy in some way the control flow, but when used correctly, they can simplify things a lot and make your code even more readable and maintainable. Even the official standard library uses `goto`.
c# implementation of LINQ and some of their other features use goto. I assume there is a usecase for everything, its' just discouraged since people would abuse it.
Goto is usually considered harmful but can be employed for good in error handling and cleanup. However, I feel like golang's defer do a much better job here so I would refrain from goto unless strictly necessary. That would usually be, as you said, performance critical codepaths which should not be taken lightly.
Goto was put into Go for good reason and was combined with support for labels and some sensible restrictions and admonitions in the language specification. So it should be used--when appropriate. I feel the primary use case is precisely then, when you absolutely HAVE TO break the control flow. So far, this happened to me only once in a situation where this was the best solution I could come up with in regard to an algorithmic problem. So I think this is mostly for these kinds of things.
ich bin gerade dabei Go zu lernen. Vor ein paar Wochen waren die Inhalte deiner Videos noch etwas tricky für mich, aber so langsam geht es ;-) Toller Kontent, vielen Dank dafür. Sehr sehr hilfreich
@@last_fanboy_of_golb Not quite, but it's close. It's more like in the direction: "I am currently learning go, and a few weeks ago it was tricky, but now he is getting comfortable with it"
When it comes to the new keyword what is the difference between return new(Counter) and return &Counter{} if any. Is there a performance benefit by any chance
there should not be a performance difference, but the only way to truly know this is benchmarking. the compiler would recognize that the memory escapes the function scope so it has to be heap allocated. the only difference is that {} you can specify initial values
I agree; there shouldn't be any performance difference because the Go compiler optimizes both expressions similarly. I think this is a valuable discussion: groups.google.com/g/golang-nuts/c/GDXFDJgKKSs
Generally speaking you should avoid labels. They are one of the features of Go that hurt the language in a big way. Labels and Goto are horrible and should be avoided at all costs
I agree, generally speaking you should avoid these, especially for simple flows. However, they do exist for a reason, and even the standard library of Golang uses both concepts. Obviously, they should be used judiciously. But, especially for things like simplifying error handling and cleanup code (in some cases) can lead to more readable and maintainable code.
@@FloWoelkiyes that is the point. Its like a go sub or call func in long infinite chain call. Like call func1 and in func1 call func 2 and son on. In this case we are dividing and specialiating code but in a bad way of control. Is the same with labels in go. If you use in a propper way no problem. People are afraid of goto because of basic where you can go to anywhere in the code but labels in go are fantastic tool
It would be pretty much better if you skip saying pretty much so you should pretty much stop saying pretty much. Just kidding, thanks for the efforts to make Golang popular.
"goto nextIteration", in you rexample, is the same than "continue" keyword. But goto is well known since ever (asembly code even in micro-controler 8 bits) as an "inconditional jump". It is a bad practice there.
😂 please. That was said in a context totallundiferent where go to was used indicriminated as in basic where you can jump to anywhwere in the code. This is no the case
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
13:36 avoid weird syntax, refactor the code to put the inner loops into a function and replace the goto with a return
I've been writing Go for a month, but have 5 years in industry. These are all pretty basic concepts in Go. Also don't use goto. It destroys control flow and there are other ways to do what it enables. If you look at C, goto exists, but you really only see its use when taking emergency recovery actions like in the Linux kernel.
I agree with you, but it's definitely good to know the concepts.
Sure, they do destroy in some way the control flow, but when used correctly, they can simplify things a lot and make your code even more readable and maintainable. Even the official standard library uses `goto`.
c# implementation of LINQ and some of their other features use goto. I assume there is a usecase for everything, its' just discouraged since people would abuse it.
Goto is usually considered harmful but can be employed for good in error handling and cleanup. However, I feel like golang's defer do a much better job here so I would refrain from goto unless strictly necessary. That would usually be, as you said, performance critical codepaths which should not be taken lightly.
Goto was put into Go for good reason and was combined with support for labels and some sensible restrictions and admonitions in the language specification. So it should be used--when appropriate. I feel the primary use case is precisely then, when you absolutely HAVE TO break the control flow. So far, this happened to me only once in a situation where this was the best solution I could come up with in regard to an algorithmic problem. So I think this is mostly for these kinds of things.
You might not have set out to explain bit shifting but you did a pretty good job of simplifying the concept
Thank you :) I might make a video about bit shifting in the future.
ich bin gerade dabei Go zu lernen. Vor ein paar Wochen waren die Inhalte deiner Videos noch etwas tricky für mich, aber so langsam geht es ;-) Toller Kontent, vielen Dank dafür. Sehr sehr hilfreich
Freut mich sehr, dass es dir weiterhilft! :)
I dunno german but i bet my ass he said it's been great learning Go in the first sentence
@@last_fanboy_of_golb Not quite, but it's close. It's more like in the direction: "I am currently learning go, and a few weeks ago it was tricky, but now he is getting comfortable with it"
More videos like this please!
Sure, I'll try my best!
simple and to the point, thank you :)
Glad it helped! :)
I really like your video editing skills, how can I achieve a similar look in my videos? which program are you using for the edits?
Nice golang focused videos, added to my library.
That's awesome, thank you :)
Great content!
Thank you so much! :)
For me go to is label break just for bring some clarity. Because goto outherloop is better that just break
amazing video, can you please have your dev setup on the laptop + desk tour video.
good stuff!
Thank you :)
great stuff
Thank you :)
what theme is that?
It's the GitHub theme :)
When it comes to the new keyword what is the difference between return new(Counter) and return &Counter{} if any. Is there a performance benefit by any chance
there should not be a performance difference, but the only way to truly know this is benchmarking.
the compiler would recognize that the memory escapes the function scope so it has to be heap allocated. the only difference is that {} you can specify initial values
I agree; there shouldn't be any performance difference because the Go compiler optimizes both expressions similarly.
I think this is a valuable discussion: groups.google.com/g/golang-nuts/c/GDXFDJgKKSs
@loo_9 and @FloWoelki thanks for taking the time to reply.
From now on I'm going to start quoting "This is somehow a problem, cuz it's not really beautiful and it is really really ugly" daily hahahaha
That's the spirit :D
iota is a greek word and is pronouced iota.
Generally speaking you should avoid labels. They are one of the features of Go that hurt the language in a big way.
Labels and Goto are horrible and should be avoided at all costs
I agree, generally speaking you should avoid these, especially for simple flows.
However, they do exist for a reason, and even the standard library of Golang uses both concepts.
Obviously, they should be used judiciously. But, especially for things like simplifying error handling and cleanup code (in some cases) can lead to more readable and maintainable code.
@@FloWoelkiyes that is the point.
Its like a go sub or call func in long infinite chain call. Like call func1 and in func1 call func 2 and son on. In this case we are dividing and specialiating code but in a bad way of control. Is the same with labels in go. If you use in a propper way no problem. People are afraid of goto because of basic where you can go to anywhere in the code but labels in go are fantastic tool
It would be pretty much better if you skip saying pretty much so you should pretty much stop saying pretty much.
Just kidding, thanks for the efforts to make Golang popular.
0:46 iota is not an acronym (for what?), it's a Greek letter. You spell it eota or yota.
"goto nextIteration", in you rexample, is the same than "continue" keyword. But goto is well known since ever (asembly code even in micro-controler 8 bits) as an "inconditional jump". It is a bad practice there.
"Go To Statement Considered Harmful" -Edsger Dijkstra
😂 please. That was said in a context totallundiferent where go to was used indicriminated as in basic where you can jump to anywhwere in the code. This is no the case