This paragraph is scary. It looks like a good idea for the Golang version of the Underhanded C Contest.<p>> <i>This trick is useful for returning a slice from an immutable array; if you accidentally append to the supposedly immutable slice, a copy is forced and no data is overwritten because there is no more capacity left.</i>
why do people write articles about go features? when PHP was in its prime, almost nobody wrote blogs explaining how they found some philosophy in PHP. there's a reason for that.<p>when you see someone open their article explaining a language feature by talking of the implementation details or specific use cases, that's a language smell (of course all industrial PLs stink).<p>ironically go is the only post 80s language that uses "memory safe" as a marketing point (even though they all are), yet go has the most memory unsafety of post 80s industrial languages. you can parse something and pass on a slice somewhere. if you mistakenly slice that slice with a bigger size - this incorrect size being the programmer bounds check error - you restore some of the original array that was supposed to be cut off and teh next operation working on that slice will thus modify or leak data:<p><pre><code> package main
import "fmt"
func main(){
a := [3]int{1,2,3}
b := a[0:2]
fmt.Println(b[1])
c := b[0:3]
fmt.Println(c[2])
}
$ go run a.go
2
3
</code></pre>
the other example of memory unsafety in go being that modifying slices between threads can lead to actual memory corruption, not just simulated memory corruption as above<p>the point here is that this footgun doesnt even have a real point outside of some insane performance argument. nobody would ever design something like this without massive cognitive dissonance (aside from industrial PLs, which just copy and modify the previous industrial PL, C in this case). all go's primitives are rigged like this with unintuitive behaviors. its amazing how much such a simple language with small scope can get wrong. and i expect nothing less from people who go around saying "zeroeth". DAY OF THE BOBCAT SOON
Tangential, but if OP is the owner of the site, could you talk a little bit about your book writing process?<p>- How you write<p>- How you render the PDF<p>- How you develop your plans<p>That kind of thing. I find it super interesting to self-publish software books and I've been slowly writing one for about a year now. Really curious about this stuff in general and it looks like you've got a solid process down.
My fave golang slice trick is the len of an empty slice is 0, but the slice itself is == to nil, but the len of nil won't compile. Can't understand that one.<p><a href="https://go.dev/play/p/MslCkBphl7q?v=gotip" rel="nofollow">https://go.dev/play/p/MslCkBphl7q?v=gotip</a>
Question: what is the reason for the silent copy when append exceeds the original slice cap?<p>It's a footgun avoided by reading the spec and (maybe) remembering it in practice, but it feels like it would be safer to throw a comp error and force the user to deal with it when a user is trying to exceed the cap of the underlying array?<p>Alternative is defensively using len() and cap() for slice ops in which case error-ing out feels more ergonomic.
0. Only 2 of 3 values are necessary.<p>1. Can 1 value be unspecified?<p>2. Can 2 values be unspecified?<p>3. Can 3 values be unspecified?<p>4. Are conflicting values interpreted as intersection of ranges rather than union?<p>Note 1-3. With 2 values, I believe x[:] is how to lift a sized array into a more generic slice type.