Hacker News Reader

Comment by sabellito | Hacker News Reader

I haven't done any Go in my life, but this bit about immutability interests me. Is there a general movement in the Go community towards immutable data structures?

View on HN

I don't think there is a movement towards immutable data structures. The const keyword only works on basic types (bool, num, str). Objects can have private member variables, but those are only private on the module level. You can also pass by copy instead of passing a pointer.

This is something I'm hoping will change with the introduction of Generics. Right now using any custom data structures like immutable map or lists are very cumbersome requiring either code generation or runtime type coercion via `interface{}`.

Go espouses "Share by communicating, don't communicate by sharing" i.e. don't let goroutines communicate by mutating shared data, but then doesn't provide any effective immutable data structures to make this easy.

Being able to safely send pointers to immutable maps over channels would make go very nice to work with. Although I'll never use Go outside of work until they remove nullable pointers which seems unlikely.

Channels. Share information between routines with channels. If you're passing pointers to mutate down a channel, then that's on you. Just set yourself on fire, much easier that way lol.

You don't need immutable structures to communicate between goroutines. Value types are fine. Just think a bit about how to use channels as signal carriers, it eventually starts to make sense

I think I miscommunicated what I meant, there was an implicit assumption that copying value types over channels was bad due to GC overhead. Efficient Immutable data structures let you have your cake and eat it too. You can avoid GC overhead by sharing structure but avoid problems with mutation between goroutines.

Reply on news.ycombinator.com