7 common mistakes in Go and when to avoid them by Steve Francia (Docker)

[@hz8711]

These kinds of talks where the presenter is a true expert in his field.

[@marioskrlec6595]

I'm on a Go youtube lectures spree and every time a finish one of them, I wanna refactor all the code I've done so far :)

[@prakashsharma-uv4pj]

Please share the channel url

[@moriumbegum4180]

P

[@shiskeyoffles]

@@prakashsharma-uv4pj ??

[@graysonelias8334]

You probably dont care but does someone know a tool to log back into an Instagram account?? I was dumb forgot my password. I appreciate any tips you can offer me!

[@MrSkinkarde]

Why don’t you make actual code ?

[@bryanenglish7841]

Still easily one of the best Go "best practices" video on youtube

[@saimonshaplygin7867]

My video tags and descriptions: 1) Don't user interfaces 3:19 2) Don't use io.Reader & io.Writer 6:24 3) Requiring brod interface 8:44 4) Method vs function 10:41 5) Pointer Vs Value 14:58 6) Error is does not a string 16:56 7) To be safe or not to be 22:14 P.S. Top secret skill: 24:56

[@malcolmgdavis]

Pointer vs. Value discussion: Based on the Method vs. Function discussion, ADT should be strictly adhered to. Operations that modify the ADT are modeled as functions that take the old state as an argument and return the new state as part of the result. In other words, a function should enforce immutability. The ADT approach helps with concurrency, making the code cleaner and easier to read. As an API user, I shouldn't worry about the state changing when I pass a structure. Of course, the pure ADT model's problem is memory consumption. That's why ADT models are generally implemented in VMs that can routinely find old structures without references and remove them from memory.

[@naikrovek]

There needs to be a book on these. He's racing through concepts that could use a lot more detail.

[@guitaripod]

Good talk. It's cool to watch this in 2022, as it can be considered ancient relative to Go's lifetime

[@nano_sweet]

I sincerely believe that io.Reader and io.Writer are the two most powerful interfaces in the language. They're so underrated that it kind of makes me sad.

[@BRUHItsABunny]

i used to dislike them until i finally understood Go polymorphism

[@richardchaven]

ahhh. it makes me remember my younger days with TStrings ...

[@mateoleoncamacho3222]

Agreed. And nice pfp btw.

[@DenisG631]

Methods not necessary imply mutation, therefore generating shortcodes (13:00) can be a method as well, maybe even a lazy var which is instantiated only once. Languages like C++/Swift have const/mutating keywords for indicating a method mutating or not mutating its fields

[@WesRoberts42]

I agree, the method vs function idea smells like a false dichotomy

[@youtux2]

Yeah I remember the "const" keyword in C++ to declare methods that would not write to the object state... Thanks for mentioning :)

[@daniellee3987]

Agreed. Say if there are bunch of functions that always reference the same data type to perform some computation, naturally I would feel its more cohesive if those functions and the data belongs together, the data being the state and functions being the methods.

[@LPFan33]

Scott Meyers also wrote a guideline about this w.r.t. C++: "Prefer non-member non-friend functions to member functions. ". I think its essentially the same advise. In short, if your function can depend exclusively on a classes public interface, then do so. He argues it creates better encapsulation. Some benefits that I have observered are higher testability and extensibility.

[@chmod0644]

Good talk. Hugo powers my blog, and I love it!

[@jengo1]

Fantastic talk! I am new to go and had no idea on the proper way to handle errors. I am off to fix my code :D

[@AndreiDinTheHouse]

Pointers vs values - it's not just about usage. "If you want to share it, use a pointer" is a pretty contextless way to describe an issue that can easily become sensitive. Don't share unless you absolutely need to is a better way because otherwise a good starter is: I'll share because it's more flexible and I'll see about it later. But memory allocation is an important point as overusing pointers is a sure way to shoot yourself in the foot sooner rather than later.

[@castmetal]

Thank you very much! Great presentation to us!

[@xmlviking]

Excellent talk I really appreciated the code examples :) Nicely done sir.

[@PetrGladkikh]

Almost all of them are not actually Go-specific mistakes. In particular those are the same for most JVM languages.

[@jeeplin6529]

i am from china. and learn a lot from this video. tkx

[@notangryjustdismayed]

i am from canada, and i also learned a lot from this video.

[@XYZ-ee8fl]

I am a Chinese living in Canada, I learned two tons from this video.

[@ngocha5354]

I thought China banned KZbin?

[@Harry-qh5rt]

I'm Canadian living in Canada and dereferencing a pointer is faster than resolving a variable name to value (symbols table lookup, making a copy of the data, etc). If you have the need for speed, then grab a dog and make it a pointer! Equally important is that reference by value is making a copy of the data, and then you get into the deep copy versus shallow copy issues (not sure yet how GO handles this). Major pain in the ass. I am new to GO, but not to C and other object oriented languages (e.g. smalltalk, C#, etc.). The trade off always has been speed versus code manageability. So you have to ask yourself, do you feel lucky? Well, do ya punk?

[@arnold6644]

im from china too, and learn now. by the way , we blocked youtube, but we never block knowledge

[@romand1979]

In the example for using functions over methods when no side effects are intended I'd argue that *Page should be Page instead - its a clearer argument for expressing no side-effects when you have a value receiver where side effects are not possible.

[@xleelxz]

TL;DR - Big Page cost twice the memory if passed by value. The readability is a bonus, but for large Pages, passing a pointer, even without modifying it, tends to be faster and more memory-efficient than passing by value and inevitably having the whole Page copied.

[@romand1979]

Thanks. I'm just learning Golang but I love the idea of immutability.

[@MaximeFRYSOU]

If a method is supposed to modify the state (vs functions), how come you wouldn't use a pointer in a receiver...?

[@danaadalaide5648]

Just to be clear, maps are the only issue with concurrent access. A quick fix is to use sync.Map, but in a lot of cases using a drop-in replacement using a slice of struct{k,v string m Mutex} is slightly faster as you only need to lock on write with a high load of concurrent access.

[@yotubecreators47]

Thaaaaank you, some one should collect all these pull request reviews and upload it in one website with git diff + comments :D

[@CheyneWallace]

Really great talk. Thanks for this

[@danaadalaide5648]

Also, internally.. Channels use mutexes anyway, so its not necessarily a bad thing to use..

[@kkmingming]

You are a rock star!!!

[@robfielding8566]

the real problem with not using a reader is that the buffers might be really large.

[@impaque]

Great stuff, thanks for the lecture!

[@toofracing7104]

Really good stuff!

[@brucewang2072]

Very helpful, Steve!

[@johnnybravo4045]

The 8:30 slides shows that the code is not correct. Marshalling in a computer science is the process of transforming the memory representation of an object into a data format suitable for storage or transmission. In above slide the logic is actually doing the opposite. It transforms data coming from storage or transmission (in Reader) into memory representation v.config (out). The function in Viper should be called unmarshalConfig.

[@classicguy7813]

Sirrrr, it is great 👍

[@skylvid]

Awesome talk. Good sound too.

[@aisi0o0taisi]

Am I a complete noob or did you forgot to explain why those patterns are mistakes?

[@causeno1048]

9:49: I would argue that this design principle applies to OO interfaces just as well.

[@MrTripi]

interface segregation.

[@mister-ace]

@@MrTripi yep

[@sanketg10]

Really good talk! I learnt a lot. Am coming from Python!

[@a0um]

Hey, if I may ask: how many years of Python coding have you done? What made you want to try Go? Are you still doing Go?

[@malinyamato2291]

great sensei .... got me up to speed on docker.

[@林楷涛]

how should i understand "time is ticking"?

[@gemini_537]

It is about concurrency, if it uses pointer instead of value, another goroutine might modify the value while this one is running.

[@TV20]

If you use time as pointer, some milisecond may elapsed untill t.sec and t.nsec call and that will cause function never works as expected. thats why you must use as value to copy current value and compare it in function

[@pengdu7751]

great talk

[@dabbopabblo]

I don’t know if I’d say go is a new language anymore

[@goat5249]

Alright, you convinced me. I'm going to stop watching videos and go fail now!

[@brians7100]

In Java, almost everything is a pointer.. things are passed by reference by default with the exception of primitive unboxed numerics

[@shahmiBro1]

great talk;

[@pavelerokhin1512]

nice!

[@doufuwang]

After reading some pieces of Go code of Ethereum I finally land here.

[@ailuros_]

Except the fastest static site generator is not "Hugo" anymore but "Zola" (written in Rust). Good talk btw

[@watcher8582]

Thanks

[@alexanderzhang3972]

受益匪浅。

[@mikei4min]

Great!

[@omonkerman]

COOL. GOT IT!!! 😆

[@MariusKavaliauskas]

why are p.BaseFileName() and p.lineNumRawContentStart() not functions but methods? (at 13:04)

[@bukhorimuslim3412]

Biggest Mistake; Not Makimg Mistakes

[@levani7851]

wild Francesc appears at the end

[@9ShivamSharma]

12:53 NO

[@JacquesBoscq]

*gling* *gling* *gling* :}

[@malcolmgdavis]

The method vs. function debate is absurd. The presenter needs to learn or spend time with OO programming. Class methods don't have to be logically connected to states. I developed in C during the 80s. The problem with structs is that the data is the point of coupling. The class hides data. In OO, the focus is on behavior and not the state. The OO state can be anywhere and can change. The strategy allows the implementation of the module to be changed without disturbing the client programs.

[@moneyluser5711]

too slow and fluffy to be useful