4 ms·

One correction: Go slices also own their memory, so their equivalent would be Zig's `std.ArrayList`. Slices in Zig are just ptr+len, so you will have to manage

• masklinn 4y ago
  > One correction: Go slices also own their memory They both do and don’t, which is a major issue with the language. If you create a slice from an array, it’ll use that array as backing buffer. Likewise if you reslice and existing slice. But because it also has an arraylist interface (kinda, it’s a bad one) you can quite easily stomp on other slices using the same backing buffer.
  • Joker_vD 4y ago
    Oh yes, I've had some quite hilarious (read: infuriating to debug) bugs because of that behaviour. I imagine that's why almost everyone just use slices exclusively: you rarely if ever see "[SomeConstant]whatever { ... }" or even "[...]whatever { ... }" in Go codebases, it's almost always just "[]whatever { ... }": such literal slices have copy-on-append behaviour. And the syntax really nudges you into it which is nice.
    • masklinn 4y ago
      > such literal slices have copy-on-append behaviour. Only because literal slices default to cap == len (and a buffer of the same size). But if you create a sub-slice then all bets are off. That’s why some folks recommend always using a “full slice” if the result escapes: A[x:y:y] This way the cap() is set to the same value as the len(), and append will always trigger a copy. Essentially a cheaper (but riskier) version of a defensive copy.