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

Go structs are copied on assignment (and other things about Go I'd missed)

jvns.ca

Post reply on HN
Print view View original

171–176 of 176 posts

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#171

Post by teivah »

metadat wrote: post #165
teivah wrote: post #164

Earlier quoted context omitted.

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 t…

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.

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#172

Post by B-Con »

everybodyknows wrote: post #166
B-Con wrote: post #139

Earlier quoted context omitted.

Technically no, but I get why it feels like this. :-) I think the confusion stems from the fact that Go hides the distinction of "dot" access vs "pointer dot" access. (eg, the difference between `foo.Bar` and `foo->Bar` in C++). Go knows if an object is a pointer and needs to be de-referenced, and hides the de-reference operation from you syntactically. So you can use a pointer without knowing it's a pointer. This is…

From Google's Go project blog: > Map types are reference types, like pointers or slices. https://go.dev/blog/maps

Actually, here's an example of precisely why maps are not passed as references:

https://go.dev/play/p/-mEeg2Ud68V

This example cannot re-allocate the original map! If the map were truly passed by reference, it could be allocated in a local function. But it can't, only values within the map can be modified when a map is passed.

This is in contrast with pass by reference in, say, C++, in which case you can assign directly to and modify the reference. ex: https://www.ibm.com/docs/en/zos/2.4.0?topic=calls-pass-by-re...

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#173

Post by kiitos »

tapirl wrote: post #170
kiitos wrote: post #169

Earlier quoted context omitted.

It's very clear that the reason these kinds of proposals haven't been accepted has nothing to do with the core team not believing they're important enough, but instead because of the impact that they have on the rest of the language.

What impact in your opinion?

Immutability is a fundamental property of a language, it's not something that can be bolted on post-facto in a version update. Go as a language doesn't provide immutability.

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#174

Post by tapirl »

kiitos wrote: post #173
tapirl wrote: post #170

Earlier quoted context omitted.

What impact in your opinion?

Immutability is a fundamental property of a language, it's not something that can be bolted on post-facto in a version update. Go as a language doesn't provide immutability.

If the "for ;;" loop semantics can be bolted on post-facto in a version update, nothing else couldn't.

Go provides certain immutability.

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#175

Post by kiitos »

tapirl wrote: post #174
kiitos wrote: post #173

Earlier quoted context omitted.

Immutability is a fundamental property of a language, it's not something that can be bolted on post-facto in a version update. Go as a language doesn't provide immutability.

If the "for ;;" loop semantics can be bolted on post-facto in a version update, nothing else couldn't. Go provides certain immutability.

It does not. Believe what you will.

Re: Go structs are copied on assignment (and other things about Go I'd missed)

#176

Post by tapirl »

kiitos wrote: post #175
tapirl wrote: post #174

Earlier quoted context omitted.

If the "for ;;" loop semantics can be bolted on post-facto in a version update, nothing else couldn't. Go provides certain immutability.

It does not. Believe what you will.

You are not familiar with Go.
Post reply on HN