?

Can you give me an example? Java's `finalize` is not deterministic destruction. D's scope guards (or Go's `defer`) are also not like destructors, because a calling code has to take care of them.

> It is a matter of enjoying productivity it offers,

There's hardly any productivity gain, and it is being offset by productivity gained by a reliable and hassle-free resource management.

Edit: Oh, and if you don’t think that’s enough, note that Rust doesn’t guarantee destruction to ever occur in that case (“considered safe”): https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Not quite.

https://docs.python.org/3/reference/datamodel.html#object.__...

> It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits.

With `with`I can't eg. pass an open file to another function to eg. be closed there etc.

Example:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

closing `File` will happen at the end of `foo` or `foo2`.

That's true, since Python has reflection it can't easily optimize that case, whereas that's a powerful benefit of having a linear type system for tracking ownership like Swift or Rust. But early freeing (which Rust has and Python does not) is slightly different from deterministic freeing (which both have) is slightly different from guaranteed freeing (which CPython has and Rust does not).

Dealing with borrow checker on cases that are still being worked on (NLL 2, GUI callbacks), using unsafe for graphs or dealing with use-after-free array indexes for the alternative workaround, unsafe Drop implementations, doesn't look hassle free to me.

> using unsafe for graphs or dealing with use-after-free array indexes for the alternative workaround, unsafe Drop implementations, doesn't look hassle free to me.

Valid points, but these are rare problems in idiomatic Rust.

Specifically avoiding graphs by structuring code into a tree of ownership, has greatly improved architecture of my programs, to the point that I just do it like this in all programming languages I use.

Rust made me realize how many problems objects carelessly cross-referencing each other (especially in OOP) - "because there's a GC, so why not" create.

Similar with array of indexes - great improvement both in usability and reliability. At least all use after-free in that case is checked and fails deterministicly. It makes my data with graph-like, or relationship properties resemble relational database.

For problems with lifetimes in destruction all I needed so far is https://crates.io/crates/dangerous_option . I actually wish it was part of language (a nullable types, panicking at runtime).

Yes they are, they get called at the end of scope.

> Valid points, but these are rare problems in idiomatic Rust.

Being rare doesn't mean they aren't there, and anyone trying to write UI related code will deal with them on regular basis.

Can you clarify, what am I misunderstanding here? In couple of places online I've found that you can't depend on dtor being called.