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!
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.
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
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
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.
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.
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?
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.
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.
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.
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.
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.
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
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.
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 :)
Please share the channel url
P
@@prakashsharma-uv4pj ??
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!
Why don’t you make actual code ?
These kinds of talks where the presenter is a true expert in his field.
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.
Still easily one of the best Go "best practices" video on youtube
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
There needs to be a book on these. He's racing through concepts that could use a lot more detail.
Good talk. Hugo powers my blog, and I love it!
Good talk. It's cool to watch this in 2022, as it can be considered ancient relative to Go's lifetime
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
I agree, the method vs function idea smells like a false dichotomy
Yeah I remember the "const" keyword in C++ to declare methods that would not write to the object state...
Thanks for mentioning :)
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.
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.
i used to dislike them until i finally understood Go polymorphism
ahhh. it makes me remember my younger days with TStrings ...
Agreed. And nice pfp btw.
i am from china. and learn a lot from this video. tkx
i am from canada, and i also learned a lot from this video.
I am a Chinese living in Canada, I learned two tons from this video.
I thought China banned UA-cam?
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?
im from china too, and learn now. by the way , we blocked youtube, but we never block knowledge
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.
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
Thank you very much! Great presentation to us!
Excellent talk I really appreciated the code examples :) Nicely done sir.
If a method is supposed to modify the state (vs functions), how come you wouldn't use a pointer in a receiver...?
Almost all of them are not actually Go-specific mistakes. In particular those are the same for most JVM languages.
Great stuff, thanks for the lecture!
You are a rock star!!!
Really great talk. Thanks for this
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.
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.
Thanks. I'm just learning Golang but I love the idea of immutability.
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.
Also, internally.. Channels use mutexes anyway, so its not necessarily a bad thing to use..
Really good stuff!
Very helpful, Steve!
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.
the real problem with not using a reader is that the buffers might be really large.
Am I a complete noob or did you forgot to explain why those patterns are mistakes?
great sensei .... got me up to speed on docker.
Sirrrr, it is great 👍
Awesome talk. Good sound too.
Really good talk! I learnt a lot. Am coming from Python!
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?
how should i understand "time is ticking"?
It is about concurrency, if it uses pointer instead of value, another goroutine might modify the value while this one is running.
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
great talk
I don’t know if I’d say go is a new language anymore
Alright, you convinced me. I'm going to stop watching videos and go fail now!
9:49: I would argue that this design principle applies to OO interfaces just as well.
interface segregation.
@@MrTripi yep
great talk;
COOL. GOT IT!!! 😆
Thanks
Great!
In Java, almost everything is a pointer.. things are passed by reference by default with the exception of primitive unboxed numerics
After reading some pieces of Go code of Ethereum I finally land here.
受益匪浅。
Except the fastest static site generator is not "Hugo" anymore but "Zola" (written in Rust). Good talk btw
Biggest Mistake; Not Makimg Mistakes
wild Francesc appears at the end
why are p.BaseFileName() and p.lineNumRawContentStart() not functions but methods? (at 13:04)
*gling* *gling* *gling* :}
12:53
NO
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.
too slow and fluffy to be useful
Thaaaaank you, some one should collect all these pull request reviews and upload it in one website with git diff + comments :D
nice!