I sometimes dream of a GCed language with a non-escaping pointer type. However to make it really useful (i.e. let you put it inside other non-escaping structs) you need something on the scale of the Rust borrow checker, which means adding a lot of complexity.

it's not hard. GC lets shit leak until it decided to clean it up...

do you think they will enable Valgrind if there's no leaks?

Golang has a feature that I love in general but that makes it very easy to keep unintended allocations around. If you have a struct with a simple int field, and you store that somewhere as an *int, the entire struct and anything it points to will be kept alive. This is super useful for short-lived pointers, and super dangerous for long-lived pointers.

Most other widely used GCed languages don’t allow the use of arbitrary interior pointers (though most GCs can actually handle them at the register level).

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.

there are many ways:

    - you can create deadlocks
    - spawn goroutines while not making sure they have proper exit criteria
    - use slices of large objects in memory and pass them around (e.g. read files in a loop and pass only slice from whole buffer)
    - and so on

> it worked fine after spending an hour making a suppressions file.

So you are confirming the problem, but treating it as if ignoring it is the solution for all?