I wanted (and miserably failed) to show that Go wasn't pass by reference (which a lot of people, including on HN, insist that it is, even though the docs and the behavior are quite clear). Of course the simplistic example doesn't make much sense, why not just reassign u.Name? My point is that you can't simply reassign u (as other have pointed out, you can by dereferencing a pointer to a pointer...which is still pass by value)
I have never seen Go described as pass-by-reference, especially when it doesn't have references to begin with (in the C++ sense of evaluating what it points to instead of the address itself).
I think you're still pretty fundamentally confused.
RE: "Go is pass by reference": I don't see anyone claiming that. The top comment is trying to be nice by saying that you can emulate pass by reference by passing a pointer (but you're really just passing the pointer by value).
I mean, what do you think this Java code prints (objects are references, but passed by val):
You should also consider the good comment above displaying how you actually CAN do REAL swapping in Go: http://news.ycombinator.com/item?id=5357959 (try that in Java... heh)
If you write that in C#, and declare the argument as "ref User u", it'll print "newName". Which is what I think pass by reference is. Java and Go (and C) are pass by value.
When I started learning Go, I kept seeing people talk about pass by reference, so I assumed it really did pass by reference (despite being uncommon). I was surprised to find out that it does pass by value.
Well, like I said, I've never seen anyone claim Go as pass-by-reference. That having been said, the spec refers to slices and maps as "reference types" but it doesn't mean they're pass by reference. They're still passed as a pointer, you just don't see it.
You're correct about the "ref" keyword in C#, when used for the arg and parameter, it causes the function or method to act on the same chuck of memory as the alias represented in the caller.
