Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no pass by reference in Go

dave.cheney.net

Post reply on HN
Print view View original

11–20 of 70 posts

Re: There is no pass by reference in Go

#11

Post by jbooth »

bsaul wrote: post #7
maxpblum wrote: post #3

I haven't used Go before; is there a common conception that you can pass by reference in Go?

I guess in every language with pointers, people often confuse passing the pointer as a value with passing the object as a reference.

I'm still confused and I've been working in various languages for 15 years.

If I pass a java object to a function, I'm passing a (probably) 8-byte pointer to some memory with a class tag, fields, whatever. It goes on the stack just like an 8 byte long.

In languages that support pointers more directly, I'm doing the same thing, maybe minus the class tag in the pointed-to memory. Address is in an 8 byte type, put it on the stack and access the pointed-to struct in your new frame.

Yet I've seen interview questions about whether you're "passing by reference" or "passing a reference by value" like there's some big meaningful difference and one answer is wrong.

I don't get it. Is this just one of those nerd arguments where we're debating semantics for the sake of it?

Re: There is no pass by reference in Go

#12

Post by nachexnachex »

maxpblum wrote: post #3

I haven't used Go before; is there a common conception that you can pass by reference in Go?

Some programmers make a liberal use of "passing by reference" (v. "passing by value") a variable when referring to passing a pointer to it (v. its value) to a function. This is common language in a C environment, where there's also no pass by ref (quick example: [0]). I'm guilty of this myself.

It's possible that this may create confusion to other people more familiar with, for example, the C++ concept of passing by reference which is passing an actual reference (v. "passing a pointer").

[0] https://www.tutorialspoint.com/cprogramming/c_function_call_...

Re: There is no pass by reference in Go

#13

Post by dtzur »

jasode wrote: post #10

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. - "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" definiti…

Yap, your comment is better than the entire article. Thanks!

Re: There is no pass by reference in Go

#14

Post by htns »

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.

Re: There is no pass by reference in Go

#15

Post by kstenerud »

Often, I'll deliberately give the naive "pointers are references" answer in a job interview, just to gauge the interviewer's response.

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.

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.

Re: There is no pass by reference in Go

#17

Post by mannykannot »

jasode wrote: post #10

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. - "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" definiti…

Indeed. Definition 2 is broadly in line with what "reference" means in general usage, while definition 1 is a term of art in the vocabulary of certain languages.

Before languages had reference types or pointers, the distinction between pass-by-reference and pass-by-value (or also pass-by-name in Lisp and Algol) told you important things about the semantics of the language, such as whether a function you called could modify the objects you gave as arguments, or incorporate them by reference into some other object, and how arguments that are expressions are handled. Some of those distinctions become blurred when pointers or references are passed by value; the distinction on how you pass them now becomes a distinction on what you pass. In practice, is there any language that passes pointers or references by reference?

Re: There is no pass by reference in Go

#18

Post by mannykannot »

kstenerud wrote: post #15

Often, I'll deliberately give the naive "pointers are references" answer in a job interview, just to gauge the interviewer's response. 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. If he gets annoyed or stiffens and things become tense, I'll have a good pr…

Then there are those interviewers who silently cross you off the list and move on. They are probably type II people, however, so no harm done from either point of view.

Re: There is no pass by reference in Go

#19

Post by kazinator »

mannykannot wrote: post #17
jasode wrote: post #10

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. - "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" definiti…

Indeed. Definition 2 is broadly in line with what "reference" means in general usage, while definition 1 is a term of art in the vocabulary of certain languages. Before languages had reference types or pointers, the distinction between pass-by-reference and pass-by-value (or also pass-by-name in Lisp and Algol) told you important things about the semantics of the language, such as whether a function you called could…

Don't know of any mainstream Lisp with "pass by name". Which dialects have or had that?

Re: There is no pass by reference in Go

#20

Post by lvh »

mannykannot wrote: post #17
jasode wrote: post #10

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. - "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" definiti…

Indeed. Definition 2 is broadly in line with what "reference" means in general usage, while definition 1 is a term of art in the vocabulary of certain languages. Before languages had reference types or pointers, the distinction between pass-by-reference and pass-by-value (or also pass-by-name in Lisp and Algol) told you important things about the semantics of the language, such as whether a function you called could…

It may be what reference means, but just because a language has references doesn't mean that it is passing-by-reference. There are plenty of languages that allow actual pass-by-ref, like C++. The usual litmus test is writing a function that takes two ints (not int refs!) and they're swapped at the end. In C++, you can tell because of "int&" in the signature of the function you're calling; as opposed to plain int.

In languages with macros, you get to cheat a little, and write something that looks like the above without _really_ having those semantics. However, in languages like Lisps where your macro language is extremely powerful, you might not really miss it so much.

There is a lot of convenience in _not_ having pass-by-ref! Sometimes I feel like the ardent opposition just doesn't want to admit their favorite language is missing a feature ;-) If I call a function f(a, b), I know that a, b are still pointing at the same object in e.g. Python. That is not the case in C++ (pass-by-ref) or Lisp (arbitrary macros). Predictable language semantics make code easier to reason about. That's a good thing, and it's quite plausible that the added complexity and confusion of supporting pass-by-ref isn't worth the expressiveness.

I appreciate that the term is confusing, but it does mean something. I submit that making it mean two things would be even more confusing. If it's confusing, just say "passing (an argument) _as a reference_" which is unambiguously about what you're passing, and not how you're passing it.

Post reply on HN