It is probably the case in other languages though (I believe — though I'm open to being wrong — it is in Go, string slicing is implemented through array slicing, so a substring will share the parent string's storage and keep it alive).
Are you sure? I know that a byte slice []byte is mutable, but I thought slicing a string yielded a string (and strings are immutable), an explicit conversion (and copy) is needed to get the underlying byte slice.
A friend of mine was actually asked this in an interview (how does substring works). The initial idea of taking an advantage of the immutability of an object was nice, but it turns out to be a big GC issue if your original string is extremely large.
This is why I find rust intriguing. It tracks the lifetimes using the type system, so it would be obvious to the programmer that the large strings would need to live as long as the list holding the small substrings.
I'm not a rust expert, but I believe that it's basically impossible to write something like the code in the bug report without getting a compile time error in rust. You'd either need to use a version of substring that makes a copy, or explicitly keep the large strings around.
It is one of those cases where you can actually leak memory with a GC. But at least Java gives (gave?) you a choice: to create a new string a use the current one, in .NET substring always returns a new string.
The view technique was actually great. You could write performant parsing and matching code without having to keep track of positions in the string. The current situation is much worse. You get crazy amounts of allocation and GC for code that used to produce almost none.
Even better - installing java on the mac install the ask toolbar that actually adds garbage into my search results, let alone garbage collection. Howzabout then?
