3 ms·
> But it is inefficient to pass an array or struct; instead, we should pass pointers to these types. I feel like the author hasn't used go much. You almost nev
by mediocregopher 13y ago
> But it is inefficient to pass an array or struct; instead, we should pass pointers to these types.
I feel like the author hasn't used go much. You almost never work with arrays directly, you use slices, which CAN be efficiently passed around.
EDIT: Upon re-reading I think the author was making a point about the consistency of go, and how different types have different behavior with regards to pass-by-reference/copy. There's actually a pretty simple rule for it:
If the variable is a primitive, or defined by the user, it is passed by copy (ints, strings, structs, etc...). Everything else (compositional types like slices and maps, and others like channels) are passed by reference.
The outlier are raw arrays, but again you don't ever actually use those, so you can just ignore them.
- twic 13y agoAs some one who is not familiar with Go, that sounds like it supports his statement that the type system is confusing.
- tankenmate 13y agoI think it might be stretching it a bit to say that one lesser used exception makes the whole system copy/reference system confusing. There is also the upside that if you know what you are doing you can extract significant improvements in performance by being able to specify which passing method is used; a fair number of newer languages offer you no such option.
- fauigerzigerk 13y agoI do appreciate the additional optimization opportunities that derive from the fact that user defined types can be used as values and not just references like in Java. That's very important for memory usage. But the complexity that comes with it is undeniable. It's not just one exception that is confusing. The whole business with nil interface values versus non-nil interface values that contain nil pointers is not exactly pretty. It is consistent though.
- twic 13y agoI don't dispute the usefulness of being able to control how parameters are passed, especially in a systems language. But it seems like the two ways of passing could be consistently marked by syntax. They are in C, C++, and Rust, right? In Rust, if you had some type 'channel', then: fn spam(victim: channel) takes the channel by value (impossible in Go, and probably nonsensical anyway), whereas: fn spam(victim: @channel) takes a pointer to the channel. I think the str type is currently an exception to this in Rust.
- NateDad 13y agoSo... you have the right idea, but your statement about passing is technically wrong. Everything in Go is passed by copying its value. However, slices, maps, channels, and interfaces all have small values, which are just a pointer and some other small data (length, type, etc), so passing them directly (rather than by pointer) is not a big deal.
- deleted 13y ago[deleted]