3 ms·

> I agree with what you wrote about lifetimes 100% Then you wasted a lot of time for both of us by getting sidetracked by a detail that I hadn't even mentioned

> I agree with what you wrote about lifetimes 100% Then you wasted a lot of time for both of us by getting sidetracked by a detail that I hadn't even mentioned in my original comment. This is about the issues with having one object being referenced from multiple locations. I gave a concrete example to illustrate this issue, and you spent an entire subthread arguing the specifics of the example without seeming to understand the issue it was meant to illustrate. This is not specific to maps or strings. It's a general issue of manual memory management whenever you're dealing with shared ownership of the same object. > You replied "No" to that what I wrote about Go which is not true. I think you are reading to much into an expression of disagreement. You kept fixating on the specifics of go, I was trying to get back to the semantics of GCed languages vs. manual memory management. That's what my "no" was about. Edit: I also did a quick test for Go, just to end that part of the argument, too. Contrary to your statement, Go doesn't seem to copy strings when adding them to maps, either. While there's no way to take the address of a string literal in Go, you can add lots of instances of a very large string and check the memory usage (compared to an empty string). It turns out to be nearly the same.

lossolo 10y ago
You could exactly see what I was writing about, you just didn't read it carefully enough or choose to interpret as you fit. I was right in what I wrote from the beginning. 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. So if you want to blame someone for wasting the time, blame yourself for not being specific enough and then not replying to what I really wrote. > I think you are reading to much into an expression of disagreement. You kept fixating on the specifics of go, I was trying to get back to the semantics of GCed languages vs. manual memory management. That's what my "no" was about. There was only one sentence in that comment to which you could write No, next time if you want to get back to lifetimes in discussion with someone, write "I want to discuss lifetimes" instead of writing "No" to something that someone wrote, you see a difference? Words matter. > I also did a quick test for Go, just to end that part of the argument, too. Contrary to your statement, Go doesn't seem to copy strings when adding them to maps, either. While there's no way to take the address of a string literal in Go, you can add lots of instances of a very large string and check the memory usage (compared to an empty string). It turns out to be nearly the same. 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.
- rbehrends 10y ago
  > 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
  - lossolo 10y ago
    You are doing the same again, I wrote 3 times about use case to test and you are ignoring it, living in your own bubble. This was my last message, replying to you is waste of my time.

lossolo 10y ago

You could exactly see what I was writing about, you just didn't read it carefully enough or choose to interpret as you fit. I was right in what I wrote from the beginning. 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. So if you want to blame someone for wasting the time, blame yourself for not being specific enough and then not replying to what I really wrote. > I think you are reading to much into an expression of disagreement. You kept fixating on the specifics of go, I was trying to get back to the semantics of GCed languages vs. manual memory management. That's what my "no" was about. There was only one sentence in that comment to which you could write No, next time if you want to get back to lifetimes in discussion with someone, write "I want to discuss lifetimes" instead of writing "No" to something that someone wrote, you see a difference? Words matter. > I also did a quick test for Go, just to end that part of the argument, too. Contrary to your statement, Go doesn't seem to copy strings when adding them to maps, either. While there's no way to take the address of a string literal in Go, you can add lots of instances of a very large string and check the memory usage (compared to an empty string). It turns out to be nearly the same. 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.

rbehrends 10y ago
> 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
- lossolo 10y ago
  You are doing the same again, I wrote 3 times about use case to test and you are ignoring it, living in your own bubble. This was my last message, replying to you is waste of my time.