An extended explanation missing from Dave Cheney's answer is that the "reference" etymology has at least 2 meanings. This is why his explanation is virtually the same as the one 20 years ago in the C Language FAQ[1] compiled by Steve Summit.<p>- "reference" definition 1: an alias that cannot be null which is what a "reference type" is in Pascal and C++. This might be thought of as a stricter "computer-science" definition. The C and Go languages don't have this type of "reference".<p>- "reference" definition 2: a pointer variable that lets programmers change the <i>"thing pointed to"</i> instead of the pointer variable itself to avoid copying unnecessary bytes. This is the colloquial usage. It also doesn't help that we call the star operator the "de-REFERENCING" operator[2] instead of the "de-POINTERIZING" operator. (What are we "derefencing" if it's not a "reference"?!?)<p>Cheney is talking about definition 1.<p>[1] <a href="http://www.di-srv.unisa.it/~vitsca/LAB/C-faq.html" rel="nofollow">http://www.di-srv.unisa.it/~vitsca/LAB/C-faq.html</a> excerpt:<p><pre><code> 4.11: Does C even have "pass by reference"?
A: Not really. Strictly speaking, C always uses pass by value.
You can simulate pass by reference yourself, by defining
functions which accept pointers and then using the & operator
when calling, and the compiler will essentially simulate it for
you when you pass an array to a function (by passing a pointer
instead, see question 6.4 et al.). However, C has nothing truly
equivalent to formal pass by reference or C++ reference
parameters. (On the other hand, function-like preprocessor
macros can provide a form of "pass by name".)
</code></pre>
[2] <a href="https://en.wikipedia.org/wiki/Dereference_operator" rel="nofollow">https://en.wikipedia.org/wiki/Dereference_operator</a>
"Maps and channels are not references."<p>But then refer to the Go team's article on maps:<p><pre><code> Map types are reference types, like pointers or slices, and so the value of m above is nil; it doesn't point to an initialized map. A nil map behaves like an empty map when reading, but attempts to write to a nil map will cause a runtime panic; don't do that. To initialize a map, use the built in make function:
m = make(map[string]int)
The make function allocates and initializes a hash map data structure and returns a map value that points to it. The specifics of that data structure are an implementation detail of the runtime and are not specified by the language itself. In this article we will focus on the use of maps, not their implementation.
</code></pre>
Saying maps are not passed by reference is a bit deceiving. The map's <i>pointer</i> location is not passed by reference.<p>Source: <a href="https://blog.golang.org/go-maps-in-action" rel="nofollow">https://blog.golang.org/go-maps-in-action</a>
It's a question of semantics and the poorly chosen word "reference".<p>The roots come from C, where pretty much every book on the subject talked about the difference between passing a huge, expensive value to a function vs passing a cheap pointer "reference" to it.<p>And while the semantic purists will scream and holler, the fact remains that, colloquially, a pointer is a reference to something, not the something itself. And so this annoying debate rears its ugly head a few times a year and makes it into HN or Slashdot or whatever.
Minor nit...<p>> It is not possible to create a Go program where two variables share the same storage location in memory.<p>It is possible to do so, because the empty struct occupies no space. For example:<p><pre><code> s := []struct{}{
struct{}{},
struct{}{},
}
fmt.Printf("%p %p\n", &s[0], &s[1])
> 0x176f44 0x176f44
</code></pre>
But that's kind of a fringe case, and I suppose one might argue that the two variables occupy no space so in a sense they don't share that space. Either way it doesn't detract from the original point of the post :)
Often, I'll deliberately give the naive "pointers are references" answer in a job interview, just to gauge the interviewer's response.<p>It's actually a good proxy to determining company culture. If he starts to patiently explain the difference, I'll stop him and talk about the practical implications of the concept, and we'll have a good laugh.<p>If he gets annoyed or stiffens and things become tense, I'll have a good proxy for what to expect should I make the mistake of working there.
By this obtuse definition of 'pass by reference', Nothing with a C-like function call stack will 'pass by reference'. Programming languages that approximate 'pass by reference' will actually pass a pointer to the called function that points to a value in the callee's stack frame. The pointer in the called function is a local variable, so changing the value of that has no effect in the callee's scope. Changing the contents of the thing pointed to is the only _meaningful_ 'pass by reference', and practically most languages have that. (including Go)
Interestingly, the term "reference type" has been removed from the Go spec in 2013: <a href="https://github.com/golang/go/commit/b34f0551387fcf043d65cd7d96a0214956578f94" rel="nofollow">https://github.com/golang/go/commit/b34f0551387fcf043d65cd7d...</a><p>Yet some semi-official sources (like The Go Programming Language book) <i>do</i> refer to channels as "reference types".<p>TBH, I find cheney's post not fully useful without explaining what <i>does</i> happen behind the scenes in maps so that passing them by value doesn't incur large copies.
C# has a name for Go's object semantics: Marshal By Reference. This means that when an object features in a call, the GC pointer aka reference is passed (by value) rather than the object value itself. This reference is fundamentally different from the reference concept in C++. So the term reference is semantically overloaded and means different things in different programming languages. However, the phrase "pass by reference" is language independent and the author is correct, it doesn't have those semantics.
When teaching, rather than using a special name like "pointer", wouldn't it be better to simply explain that it's a variable that holds a memory address? Once a student (e.g. who only knows a high-level language) understands that they now have to think about memory explicitly, then the behavior of such a variable will become obvious. AFAIU there are only two special features of pointers: the dereference operation and the additive arithmetic which increments in strides according to their type.
C++:<p><pre><code> void f(map<int, int> m)
{
m[0] = 0;
}
int main() {
map<int, int> t;
t[0] = 1;
f(t);
cout << t[0] << endl;
return 0;
}
</code></pre>
prints 1.<p>Go:<p><pre><code> func f(m map[int]int) {
m[0] = 0
}
func main(){
var t = make(map[int]int)
t[0] = 1
f(t)
fmt.Println(t[0])
}
</code></pre>
Prints 0.<p>So in C++ maps are passed by value.
In Go they are passed by, hmm, "not value".<p>Go could have made maps similar to C++ maps and then people could use a pointer to a map when they wanted that. As it stands maps are "different" which is not a big deal once you're used to it but still makes things a little weird if you're coming from C++.
Go lacks the C++ reference operator.
You can't write:<p><pre><code> func fn(m &map[int]int) {
m = make(map[int]int)
}
...
fn(m)
</code></pre>
You have to write:<p><pre><code> func fn(m *map[int]int) {
*m = make(map[int]int)
}
...
fn(&m)
</code></pre>
It's very C. The caller is forced to use different syntax to pass something as a pointer/reference. In C++ and Rust, you can't see from the call whether you're passing a pointer or a reference.
However, Go has pointers (just not pointer arithmetic):<p><a href="https://tour.golang.org/moretypes/1" rel="nofollow">https://tour.golang.org/moretypes/1</a><p>Does anyone know of an imperative language doesn't have references, but also doesn't have pointers? Perhaps using something like copy-on-write to pass variables to functions.
Doesn't the post stumble over right in the second section? "It is not possible to create a Go program where two variables share the same storage location in memory". So what? The C example didn't show that either.