> It acts like a dual construction to a tracing GC in many cases
yeah one of the most helpful realizations I’ve read is that tracing and ref counting are essentially two formulations of the same problem - one is finding objects that are alive (by tracing), and the other is finding things that are dead (i.e. their ref counts reach zero). and of course, every object is either dead or alive!
It's a useful realization but the follow on (unfortunately rather popular) claim that this inverse relation makes them the same thing is clearly wrong. They exhibit entirely different performance characteristics in places where it matters.
I didn't know you could do that, thanks! also, so what if I want to re-implement something that already exists? god people on hackernews are so miserable
Killing processes usually involves some combination of ps, grep, copying a pid, and running kill. To make this process slightly more efficient, I made a terminal app to list, search, and kill processes, all in one interface. Please share any feedback you have :)
I think this is a disadvantage many developers face. Their entire life's work is tied to some proprietary product and when they leave their company (or get laid off), they effectively have nothing to show for it. Sure, you have the experience and the knowledge gained, but nothing material. This is why I encourage devs to turn proprietary work into something that's "theirs." For example, writing blog posts about your work, contributing to open source (or convincing your company to opensource something you worked on), side projects, etc.
It's unfortunate that we have to do this extra work, compared to, for instance, researchers in academia or, say, a Linux maintainer, who "own" their work (or at least get credit for it).
