I was having a conversation with a developer the other day about Go. Neither of us have experience with Go, but there's a need to understand the language. I bring decades less experience to the table, so you can imagine how the conversation went. I made statements based on what I know, and then was corrected every step of the way because my understanding of computer science is far less developed than his.
I have grown calluses when it comes to being corrected by developers with more experience. It's a necessary part of the job at this point, and it works best when you accept that there are just too many things for anyone to know them all. Of course, you can just keep learning. That's the most important part is to keep learning. Don't be embarrassed by your ignorance. Be encouraged to learn another thing.
So in the conversation I made the statement that Go Slices were like Lists in C#. The comparison was immediately refuted, but my comparison was that with Lists, you can use List.Add() to just add an entity to your list. With Slices, you can append an item to a Slice. That much is sort of true. As I was very quickly corrected, there is a big difference between adding an entity to a linked list and what Go is actually doing. In Go, appending your item to a slice makes a new slice that includes your item.
Call me dense. I didn't get the problem right away. Fortunately, I got some examples from this exchange that really brought the difference into focus. If you have a linked list with 100,000 items and you add an entity, you get a new entity and an address to the list. When you add an item to a slice, Go takes your 100,000 items, makes a copy of that array with your new item on that array. You end up needing memory to handle 200,001 items instead of 100,002. This may still be hopelessly shallow. I still don't have any experience with Go. I also have very few reasons to learn about it, so maybe that won't be happening any time soon.
I have grown calluses when it comes to being corrected by developers with more experience. It's a necessary part of the job at this point, and it works best when you accept that there are just too many things for anyone to know them all. Of course, you can just keep learning. That's the most important part is to keep learning. Don't be embarrassed by your ignorance. Be encouraged to learn another thing.
So in the conversation I made the statement that Go Slices were like Lists in C#. The comparison was immediately refuted, but my comparison was that with Lists, you can use List.Add() to just add an entity to your list. With Slices, you can append an item to a Slice. That much is sort of true. As I was very quickly corrected, there is a big difference between adding an entity to a linked list and what Go is actually doing. In Go, appending your item to a slice makes a new slice that includes your item.
Call me dense. I didn't get the problem right away. Fortunately, I got some examples from this exchange that really brought the difference into focus. If you have a linked list with 100,000 items and you add an entity, you get a new entity and an address to the list. When you add an item to a slice, Go takes your 100,000 items, makes a copy of that array with your new item on that array. You end up needing memory to handle 200,001 items instead of 100,002. This may still be hopelessly shallow. I still don't have any experience with Go. I also have very few reasons to learn about it, so maybe that won't be happening any time soon.
