Why Golang's IO.READER Is More Important Than You Think

► 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.com/#mystory
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm
SUBSCRIBE OR NO MARGARITAS
╔═╦╗╔╦╗╔═╦═╦╦╦╦╗╔═╗
║╚╣║║║╚╣╚╣╔╣╔╣║╚╣═╣
╠╗║╚╝║║╠╗║╚╣║║║║║═╣
╚═╩══╩═╩═╩═╩╝╚╩═╩═╝

[@anthonygg_]

► 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

[@makesnosense6304]

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.

[@anthonygg_]

Makes sense 🫡

[@GlennLewis]

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!

[@Sanjay-iy5zf]

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

[@yusufcansert9276]

Slice is a pointer, we are using interface so it can be used with other types

[@yusufcansert9276]

I am not sure, if this video is ok

[@fsync_off]

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.

[@comfortcove]

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.

[@carylandholt]

This was excellent! Really helped me understand the use cases for readers and writers in go. Thank you!

[@kevinb1594]

Demonstrating the memory footprint of both approaches would have been better than just telling us this is how it is.

[@ThePandaGuitar]

This video is gold. More of these Go nuggets in short format

[@tranquangthang8897]

Oh Anthony on neovim setup let's go

[@goliy1]

Just today I thought he is the only one (who I’ve been watching) uses vscode and voila - not anymore 😂

[@matiasbpg]

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

[@canoozie]

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#

[@anthonygg_]

Thanks for that

[@kavy6114]

This guy deserves more views

[@anthonygg_]

We agree here 😅

[@t1m3__]

Great explanation, thanks!

[@furyfuryfury]

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)?

[@dranon0o]

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

[@natterbrot]

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!

[@anthonygg_]

100 % agree. The problem is that people will slip away from the vid and call me a yapper. Trying to find the sweet spot

[@makesnosense6304]

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.

[@iCrimzon]

​@@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

[@demmidemmi]

​@@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.

[@-mau]

neovim gigachad

[@arnoldwolfstein]

Thanks man.

[@grim.reaper]

io.Reader is the GOAT in GoLang

[@nexovec]

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.

[@anthonygg_]

Not if you read from a connection man.

[@nexovec]

@@anthonygg_ My chatbot spat out code for a tcp reader in java just fine, wdym, explain.

[@kevinz1991]

great video thank u

[@lev2590]

Audio compression hitting hard in this video

[@anthonygg_]

Struggling with audio since day 1

[@nf-racing71]

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!

[@zexzinc5138]

Why not a pointer?

[@anthonygg_]

Doesnt hook into third parties and std functions

[@Yoshidzo]

Slice is basically a pointer + length already

[@erikslorenz]

io reader and writer are the best things ever

[@eddymoreno5624]

Hello,Where can i find some Remote entry jobs in golang?

[@kruczek1986]

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...

[@guitaripod]

4k plz papi

[@hautran7559]

Sorry but can anyone explain why use []bytes that read all data from memory but io.Reader does not do that

[@GoWithAndy-cp8tz]

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?"

[@manee427]

amazing

[@prescientdove]

please install a nerd font or use the devicons bro, it makes me sad to see those question marks on your tabs :(

[@wvdeventer]

Neovim by the way

[@agent_ly]

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?

[@kevinb1594]

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.

[@agent_ly]

@@kevinb1594 no i get that, but at what point is it a bad thing? What if my bytes don’t need to be chinked?

[@tokoucin]

If reason here just avoid copying, why not just using pointer there.

[@anthonygg_]

The reason is the opt in with other libs not only the mem

[@mohamedoussous7242]

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.

[@anthonygg_]

I thought I literaly mentioned, 1. Third party and std use readers all the time. 2. Reads in chunks.

[@makesnosense6304]

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.

[@anarrzayev1366]

let's say it makes our function more generic, more dynamic... or more `goish` :)

[@pacman777]

No

[@chudchadanstud]

The absolute state? I think I'll just stick to C and Rust. Pass it by reference and use slices. Problem solved.