On: Flattening Rust’s learning curve

[throwawaymaths]

the tradeoff is that ~you have to guess where rust is doing the frees, and you might be wrong. in the end this would be strictly equivalent to an explicit instruction to free, with the compiler refusing to compile if the free location broke the rules.

It's really too bad rust went the RAII route.

[swiftcoder → throwawaymaths]

There's no guessing - Rust has well defined drop order. It also has manual drop, should you wish to override the defined order.

[throwawaymaths → swiftcoder]

sorry i shouldn't have said guess. i meant consider

[whyever → throwawaymaths]

How often do you care about the order in which objects are dropped?

[throwawaymaths → whyever]

anything where you need to have stuff run in constant time.

[mikepurvis → throwawaymaths]

If you're in hard realtime land then you can't have any allocations at all; that's a pretty different ballgame.

Destructors should be as simple and side-effect free as possible, with the exception of things like locks or file handles where the expectation is very clear that the object going out of scope will trigger a release action.

[imtringued → throwawaymaths]

Okay, but an IDE could just visualize that for you. A linter rule could force you to manually drop if you want to be explicit.