[conceit]

If thinking about ownership of orphaned data is horrible, that still doesn't mean that there is no general solution.

I can't support your argument, because I'm not capable. If I was, I probably wasn't asking in the first place.

[catnaroek]

Let me interpret the situation in managed languages from a Rust programmer's lens: All managed resources are actually owned by the runtime, and merely borrowed by your program. Thus, killing threads is “safe”: no managed resource can possibly become orphaned. The result is very pleasant as long as your program only uses runtime-managed resources. But things quickly become hairy when you want to use foreign libraries (typically written in C, or exposing C-compatible interfaces), because it's very difficult to arrange things so that cleanup routines are guaranteed to be called before your thread is killed.

[conceit]

Would seem silly to use rust for all it's safety features to then call into c libraries, anyhow. So much for Heartbleed wouldn't happen with rust.

[catnaroek]

> Would seem silly to use rust for all it's safety features to then call into c libraries, anyhow.

Why? One very important use case for Rust's unsafe sublanguage is making wrappers around C libraries that can be used in the safe sublanguage. If anything, using C libraries is more pleasant in Rust (or C++) than in managed languages, because you don't particularly need to accomodate or work around the idiosyncracies and quirks of a complex runtime system. That's pretty much the entire point of my above post (GP to this one).

> So much for Heartbleed wouldn't happen with rust.

You may not agree, but the position consistently taken by Rust is that, while avoiding unsafe code is highly desirable, it isn't always possible. What is always possible is to isolate unsafe code, so that, if the safety guarantees of the safe sublanguage are ever violated, you know what parts of your program to audit.