> but it happens to the very best teams.
I am very convinced it does not. I think where the apex between our viewpoints lies is what we recognize (or not) as "best" teams.
I am very convinced it does not. I think where the apex between our viewpoints lies is what we recognize (or not) as "best" teams.
This makes sense for K8s resources that ARE still serving production traffic. But this overall thread is about a tool to remove applications ARE NOT serving production traffic.
> Migrations at large companies can take multiple years
Depends who is in charge and who management considers worth listening to (some of us don't struggle so hard in this area).
> I can install this tool with helm in approximately half a day.
A script I wrote to find unused resources took less than 10 minutes to write.
Hackers would be immediately bifurcated into those who followed that practice and those who are helpless.
This thread is about K8s Pods (and other K8s resources) that have been sitting idle, not memory leaks in software.
As far as "spilling" memory, the problem has already been solved by Rust which does not do garbage collection because it has static memory mapping. Does this mean egregious amounts of memory won't be used by some Rust programs? No. But unlike languages with garbage collection, where Rust is using that memory it is actually doing something with that memory.
Rust makes an interesting and demonstrably pragmatic set of tradeoffs here as opposed to e.g. C/C++: treating std::move as a default (aka linear typing) prevents a lot of leaks. But it still has pointers (Arc, etc.) and it still has tables: it’s still easy to leak in a long-lived process doing interesting things. For a lot of use cases it’s the better default and it’s popular as a result.
But neither Rust nor k8s have solved computer science.