Hacker News Reader

Comment by metadat | Hacker News Reader

Not understanding structs vs pointers is a pretty basic misconception in go.

Does this trip anyone else up? I found it unenlightening / unsurprising, and the linked "100 mistakes" piece also very basic and in some cases just plain wrong.

View on HN

"Very basic" is the entire point of this exercise. Just because things are basic doesn't mean people won't misunderstand them, and won't benefit from clarification.

Which of those 100 mistakes were "plain wrong"? That would be useful feedback for the author.

As she points out though, a lot of dynamic languages don’t behave this way. A string after all points to a heap allocation; so it’s not unreasonable to think of a string as a pointer.

I've several times answered questions from people coming from dynamic languages that ask lots of questions about Go pointers. And the answer is, actually, since Go lacks pointer arithmetic, Go pointers work the way you're used to things working. It's the Go non-pointers that are the new bizarre thing you're not used to!

So there is definitely a common language heritage that will find the behavior of value copies in Go surprising. I came into Go with compiled language experience but I'd been exclusively in dynamic scripting languages exclusively for over a decade. I had to remind myself about this as well.

It’s how structs work in C though, and Go is spiritually very close to C, including explicit pointer types, address-taking and dereferencing.

Not necessarily. A string in C is usually a char. If you have a struct with a char and you copy it, you copy the pointer to the backing memory. This is analogous to Go which also has a String be a pointer to the heap, but the behavior is different.

Go’s String is a char* that behaves like a char[] when copied.

> Go’s String is a char* that behaves like a char[] when copied.

Uhh, no. A go string is (effectively) a pointer to an immutable string of characters. When you do a = b, both a and b point to the same string (i.e. each is its own string struct, containing a pointer to the exact same array of character data).

But if you try to get a byte[] from it, THEN it makes a copy.

I think the two *s merged into an italic there

Is there a typo in this? C strings are not usually structs at all. Structs also do not behave differently if they contain a char.

In those languages, nearly everything is a pointer, they just don't call it that, which causes unnecessary confusion when you need to understand what's really happening. (E.g., in Java, a String is a pointer to a string, not a string; but an int is just an int, not a pointer to an int.)

That was my reaction too, but it does point the way to a more subtle chronic ache in coding Go: the efficiency<->simplicity tradeoff between passing some large struct to a function by reference, or by copying.

The former, "by reference" is guaranteed to impose no increase in calling overhead, irrespective of the compiler's ability to optimize the object code, however fat the struct eventually grows.

The latter, "by copying" guarantees the calling function will upon return find all fields of the struct just as before -- a great aid to understanding during code review.

Yeah I'm fairly new to Go, but have done plenty of work in languages with "no pointers" (Python, Java), with pointers (Objective-C), and with "reference/value types" (Swift). I thought I was pretty proficient with all of this, but Go's implementation was really unergonomic. It feels like it's trying to be C, but treating it more like Swift has been more effective I've found. How this all interacts with nils and missing fields in structs is also not very ergonomic, and it feels like the language is obviously missing an optional type, yet I've not seen one used commonly yet.

Please let me know what's plain wrong; I'm always happy to receive constructive feedback.

The beginning item about if-else returns isn't go-specific and is low impact, and immediately turned me off / led me to dismiss the article as a waste of time.

After trudging through more of the list, you've collected a lot of good nuggets! Maybe move the if-else to the end, as it's not particularly insightful compared to the rest.

Also the shadowing, it's fine but much less interesting and unlikely to hook in your target audience up front.

Good luck!

100go.co isn't an article; it's an online summary of my book listing 100 Go mistakes. There's a sense of progression where we navigate through topics and go (generally) towards more complicated topics at the end.

Reply on news.ycombinator.com