Why Golang's IO.READER Is More Important Than You Think
Vložit
- čas přidán 26. 08. 2024
- ► Join my Discord community for free education 👉 / discord
► Exclusive Lessons, Mentorship, And Videos 👉 / anthonygg_
► 33% OFF on my Go + HTMX + Templ Course PRESALE 👉bit.ly/3UFruxO
► Enjoy a 60% Black Friday Discount on My Golang Course 👉 fulltimegodev.com
► Learn how I became a self-taught software engineer 👉fulltimegodev....
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm
SUBSCRIBE OR NO MARGARITAS
╔═╦╗╔╦╗╔═╦═╦╦╦╦╗╔═╗
║╚╣║║║╚╣╚╣╔╣╔╣║╚╣═╣
╠╗║╚╝║║╠╗║╚╣║║║║║═╣
╚═╩══╩═╩═╩═╩╝╚╩═╩═╝
► 33% OFF on my Go + HTMX + Templ Course PRESALE bit.ly/3UFruxO
► Join my Discord community for free education discord.com/invite/Ac7CWREe58
► Exclusive Lessons, Mentorship, And Videos www.patreon.com/anthonygg_
► 60% OFF on my Golang course fulltimegodev.com
Thanks for watching
It's the difference between specifying the type of data needed vs specifying something that implements functionality needed.
If you do []byte you are saying you only take this type of data.
If you do io.Reader you are saying you take anything that implements what that interface is implementing. In this case anything that implements a function with the following structure: Read(p []byte) (n int, err error)
This means that any struct that has that function can be used. Which means greater flexibility and nicer code. It also means it's easy to mock and test.
It also means that each implementation can get the data however it wants. It can be from memory, from storage, from internet. When using an interface like this it doesn't matter where it's coming from. It's just stating what it wants.
Makes sense 🫡
Another practical example is when you need to inject a gzip encoder/decoder and/or base64 encoder/decoder into your stream... with an io.Reader it is pretty trivial.
Great video... thanks for sharing!
Just finished watching "7 Common mistakes in Go and When to avoid them" by Steve Francia (spf13) where he mentioned the same and GG posted a new detailed video on that. Well, I'm impressed
Slice is a pointer, we are using interface so it can be used with other types
I am not sure, if this video is ok
Because having an interface is better than a concrete type of data - it's much harder to break/violate contract defining interoperability between different parts of software later. Future you using the lib you write today will be grateful.
This video is gold. More of these Go nuggets in short format
Oh Anthony on neovim setup let's go
Just today I thought he is the only one (who I’ve been watching) uses vscode and voila - not anymore 😂
Love your go videos - really helpful to create mental map of language native tools.
BTW. glad to see you sticking with nvim after configuration session.
This guy deserves more views
We agree here 😅
Nice. Also, one tip, neovim related; you struggled getting back to your original file (the one you gd'd on); but one thing you can do, is set up a keybind that calls: :b#
Thanks for that
Demonstrating the memory footprint of both approaches would have been better than just telling us this is how it is.
It's not true that other languages don't heavily use reader/writer, I vividly remember dealing with them like 8 years ago in java or something.
It's not actually true what some people think, that the bytes would get copied each time you pass the byte slice somewhere, since the slice itself is just a pointer with some metadata.
Not if you read from a connection man.
@@anthonygg_ My chatbot spat out code for a tcp reader in java just fine, wdym, explain.
This was excellent! Really helped me understand the use cases for readers and writers in go. Thank you!
Already vimming like a pro ❤! I think it's time to introduce more w and b to move horizontally. Great video BTW, really like your content, would love to have time to watch your longer videos
It's an excellent one and i'm fighting at work to make new comers in the language to understand composability and especially that topic
neovim gigachad
Great explanation, thanks!
I‘ll be honest, I usually do, but I didn‘t like your explanation here. Way too fast. I think your point could‘ve been clearer if you actually kept using the bytes for longer so the viewer actually sees when that approach falls apart. Thanks otherwise and keep up the work!
100 % agree. The problem is that people will slip away from the vid and call me a yapper. Trying to find the sweet spot
It's the difference between specifying the type of data needed vs specifying something that implements functionality needed.
If you do []byte you are saying you only take this type of data.
If you do io.Reader you are saying you take anything that implements what that interface is implementing. In this case anything that implements a function with the following structure: Read(p []byte) (n int, err error)
This means that any struct that has that function can be used. Which means greater flexibility and nicer code. It also means it's easy to mock and test.
It also means that each implementation can get the data however it wants. It can be from memory, from storage, from internet. When using an interface like this it doesn't matter where it's coming from. It's just stating what it wants. And in this case it can also be streamed data.
@@anthonygg_ i dont think you should worry about being called a yapper, the whole point is to teach us new methods/stuff, if the brainrot viewers cant focus then thats their problem
@@anthonygg_ the biggest point missing for my Timmy brain is that slices are passed as pointers so the memory usage is the same in both examples.
Maybe us Timmies need a longer form video on how to not ReadAll and pass io. Readers instead.
io.Reader is the GOAT in GoLang
Audio compression hitting hard in this video
Struggling with audio since day 1
Why not a pointer?
Doesnt hook into third parties and std functions
Slice is basically a pointer + length already
Great video!!
I would have loved a more detailed, slow explanation, assuming we know less.
Because people that already know and understand won't click anyways.
I liked it tho!
4k plz papi
Hey, Anthony! Thank you very much for your videos. They are very interesting and useful. You're doing a great job. Can you tell me which text editor do you use (I assume that this is one of the varieties of Vim)? Could you share your configuration config (I'm especially interested in how you implemented code completion for Golang)?
Thanks man.
great video thank u
io reader and writer are the best things ever
Neovim by the way
please install a nerd font or use the devicons bro, it makes me sad to see those question marks on your tabs :(
The sentence you provided has some minor grammatical errors. Here's a corrected version:
"Please check if this sentence is proper English. Could you give me a hint on how to organize an IDE to quickly access functions' definitions and documentation like I do? Cheers! So far, I've been using VS Code, but I can see you use something more like Vim. Am I completely wrong?"
Sorry but can anyone explain why use []bytes that read all data from memory but io.Reader does not do that
i always watch you video with pleasuere, and what be sure that i understand what you say and correct me if i am wrong, but effectiveness of the solution, i mean using io.Reader depend on what implementation we use, correct?
i mean how we will read this interface on the function where we have it pass...
Hello,Where can i find some Remote entry jobs in golang?
I love your content but I don’t think this video actually tells us why to use io.Reader over raw dogging a byte slice aside from the std always using it. I wish you went more in-depth about how it would be copying the whole slice into memory and how strict you should be when it comes to using it. For example do I need an io.Reader if I’m parsing a RESP message or any other simple byte structure?
He literally says you'd be copying the whole byte array into memory at once instead of parts by not using a reader.... Like 6 times.
@@kevinb1594 no i get that, but at what point is it a bad thing? What if my bytes don’t need to be chinked?
amazing
If reason here just avoid copying, why not just using pointer there.
The reason is the opt in with other libs not only the mem
copying isn't a problem here (btw slices are not pass by value, they work just like pointers). it's that you load all the data at ONCE, even if you use pointer you still have to allocate memory for all the data. and this is what Reader fixes, it loads the data in CHUNKS.
I thought I literaly mentioned, 1. Third party and std use readers all the time. 2. Reads in chunks.
It's the difference between specifying the type of data needed vs specifying something that implements functionality needed.
If you do []byte you are saying you only take this type of data.
If you do io.Reader you are saying you take anything that implements what that interface is implementing. In this case anything that implements a function with the following structure: Read(p []byte) (n int, err error)
This means that any struct that has that function can be used. Which means greater flexibility and nicer code. It also means it's easy to mock and test.
let's say it makes our function more generic, more dynamic... or more `goish` :)
No
The absolute state? I think I'll just stick to C and Rust. Pass it by reference and use slices. Problem solved.