> You are generalizing too much which brought this whole discussion in the first place and when I argued about specific details which I wrote in my comments you

> You are generalizing too much which brought this whole discussion in the first place and when I argued about specific details which I wrote in my comments you didn't address them at all, you were fixated on lifetimes whole time ignoring what I was writing. Because you were derailing the discussion and I was trying to get it back on track. My whole original comment was about lifetimes and GC vs. manual memory management. You were getting sidetracked by details that weren't relevant for that point, which was specifically about GCed languages vs. manual memory management in general and didn't even mention Go [1]. > No, you are wrong. Look at runtime hashmap implementation and generated assembly (go tool objdump binary_name > asm.S) for function that do what I was writing in my comments. You will see that there is a copy. If this were true, the following program would take >65 GB of memory. In reality, it requires some 110 MB. package main import ("strings"; "fmt") func main() { m := make(map[int]string) value := strings.Repeat(".", 65536) for i := 0; i < 1000000; i++ { m[i] = value } fmt.Println(len(m)) } Note that even if it were as you said, nothing would prevent Go from changing to an implementation that doesn't copy strings. [1] https://news.ycombinator.com/item?id=14115633 https://news.ycombinator.com/item?id=14115633