[dijit]

There’s ways, GC isn’t perfect.

A common one I see fairly often is opening a big file, creating a “new slice” on a subset of the file and then using the “new slice” and expecting the old large object to be dropped.

Except, the “new slice” is just a reference into the larger slice, so its never marked unused.

[giancarlostoro]

Interesting, I always thought of slices as stand-alone, I wonder if its the same in Python?

[porridgeraisin]

No, python slice syntax on lists returns a new list. Of course, the slice syntax on your own classes can do just about anything using operator overloading.

[gdbsjjdn]

A go slice is a wrapper around a normal array. When you take sub-slices those also point to the original array. There's a possible optimization to avoid this footgun where they could reallocate a smaller array if only subslices are reachable (similar to how they reallocate if a slice grows beyond the size of the underlying array).

[kbolino]

Most sublicing is just the 2-arg kind so it would not be safe to truncate the allocation even if the subslice is the only living slice because the capacity still allows indirect access to the trailing elements of the original slice. This optimization would only be truly safe for strings (which have no capacity) or the much less common 3-arg slicing (and Go would need to have a compacting GC).

Of course, the language could also be changed to make 2-arg slice operations trim the capacity by default, which might not be a bad idea anyway.

[gdbsjjdn]

Yeah I understand why they can't do it for backwards compat reasons. Considering they had the forethought to randomize map iteration order it's a big foot gun they've baked into the language.