3 ms·
> whereas a Go slice is not generally used through a pointer I think this is referring to a syntactic difference more than an implementation difference. In Rus
by oconnor663 9y ago
> whereas a Go slice is not generally used through a pointer
I think this is referring to a syntactic difference more than an implementation difference. In Rust, a &[u8] (usually called a "slice" but maybe more technically a "slice reference") is a pointer + a length. This is basically the same as Go's []byte, which is a pointer + a length + a capacity.
Rust also sometimes uses the [u8] type (without the &). This is an "exotic" type, in that it has no fixed size. It refers to the bytes inside the slice, but it's not really a pointer to them -- it is the bytes themselves, however many of them that might be. This mostly comes up when you're dealing with generic traits like AsRef or Deref, which will put the & back in all of their method signatures.
- saghm 9y agoI'm not sure that I'd agree that `[]byte` in Go is "basically the same as `&[u8]` in Rust; making a `&[u8]` will never cause a heap allocation, which is what I was trying to get at with my original comment. If I want to track down all of my heap allocations in my program in Rust, I can safely ignore all of my slices, whereas in Go, I have to carefully reason about each usage of one.
- oconnor663 9y agoGot it. In that sense a Go slice and a Go array pointer (a &[n]byte) could have the same effect, is that right? What I wanted to emphasize was that whether you're reading bytes through a Go []byte or a Rust &[u8], the same "number of hops" is happening at runtime.