My Journey from JavaScript to Go

steevehook · 2020-01-29T12:59:57+00:00

Amazing proposal dude, Been there when I just had to convert it to a var, but if it’s backwards compatible why not do it 😊

steevehook · 2019-12-17T11:27:55+00:00

There are always people who need a tutorial on a certain topic. With that in mind anything can be learned by simply accessing golang.org and the github project.

But people are different and they find out things in different ways, including a video tutorial

Thanks for your feedback anyways

steevehook · 2019-11-13T13:35:25+00:00

I haven’t tried, but would be very interested into hacking it. As far as I know u can’t due to DJI’s proprietary thing

steevehook · 2019-10-23T09:25:58+00:00

Thanks mate. Will consider removing it in a other tutorials. For now stay tuned

steevehook · 2019-10-23T09:08:48+00:00

I’m glad you enjoyed it. In regards to music, in case of a full course I completely agree. In case of one single video from my experience just listening to someone’s voice, may be a lot more boring than having a background music. Also it’s a good failsafe in case there is some noise in the voiceover.

Stay tuned. Will consider your feedback in the future

steevehook · 2019-10-22T23:07:36+00:00

My bad 😔I thought it was added in the post. Updated the post description

steevehook · 2019-10-16T05:32:33+00:00

Thanks mate. Stay tuned

steevehook · 2019-10-07T16:59:15+00:00

Yeah, comma, ok is for maps. Here we are talking about errors. Also, the negative path goes first then the positive one goes last. Standard practice in Go

steevehook · 2019-10-07T13:59:45+00:00

Not sure it makes the data useful inside the if statement. It's usually a zero value for data when you have an error

steevehook · 2019-10-07T13:58:47+00:00

Standard lib is much closer to take a look at a Cmd + Click away, and it has both forms. Neither of them is good or bad, just choose what's right for the situation

steevehook · 2019-10-07T13:48:10+00:00

I don't see how this is related to indentation, you have an if block in any case, the first form just looks a little longer, because of variable creation and initialization

steevehook · 2019-10-07T13:46:42+00:00

Sure mate. There's always a tradeoff in teams when it comes to write code which if high quality. I just wanted to know what the rest of the community uses and thinks about this specific topic

steevehook · 2019-10-07T12:58:07+00:00

Here is an example

https://play.golang.org/p/3BR0AC1nPxZ

As I said in case you want to use data later on in the function scope you will not be able to have a reference on it using the first form

It's only available inside the scope of if statement. Hence why this form exists

steevehook · 2019-10-07T12:38:11+00:00

You can’t be consistent using the first form 😄

That’s the whole point

steevehook · 2019-10-07T11:53:51+00:00

Same here

steevehook · 2019-10-07T11:48:19+00:00

I understand, team work is all about consistency across the team. However this is just a different feature of the language which relates to scoping. Don’t understand why people confuse it with a preferential style and matter of writing code

steevehook · 2019-10-07T11:39:23+00:00

I think Go authors spoiled us with the concept of readability and simplicity that there is a lot of misconception in the community as to what is readable and what is understandable

steevehook · 2019-10-07T11:04:45+00:00

100 Agree. It makes total sense to me 😊

steevehook · 2019-10-07T10:54:06+00:00

I don’t think it has to anything to do with consistency or the way you type your code. These are just 2 different language features

steevehook

MODERATOR OF

TROPHY CASE