As someone who's been using (and really liking) rust for about 6 months, there are two things in this article which are, I'd say, 'common misconceptions' about rust:

    One of the coolest features of Rust is how it automatically manages 
    resources for you, while still guaranteeing both safety 
    (no segfaults) and high performance.

In rust there are two types of code. 'safe' and 'unsafe'. The above is only true if your entire code path contains only safe code.

NOT, if you only write safe code.

That is, if you write entirely 100% safe code, and use some library that uses 'unsafe' code at a low level (this is very common; for example, an C binding or memory optimization), then rust does NOT guarantee safety.

Furthermore, there is no way to know if your code path includes unsafe code.

Rust is relatively safe; it's just not totally safe. Using rust does a reasonable job of protecting you from segfaults most of the time; but it's not a silver bullet.

    As soon as the program stops using the resource, its cleanup logic gets 
    invoked.
    
    ...

    Because only one scope owns an object at a time, you can tell just by 
    looking at it which objects will be destroyed when it's done executing.

This isn't always necessarily true.

Rust uses 'drop flags', which are extra bytes at the end of struct instances in memroy, to track objects and keep meta information about them to determine if they should be dropped.

At the end of scope when the drop checker runs it checks against these drop flags to determine if an object should be dropped or not.

(For example, if a closure captures a variable it may no be dropped at the end of the scope it would normally have been dropped in).

There seems to be this myth that resource deallocation in rust is magically determined at compile time and the has 'zero cost'; it's simply not true.

There is a runtime cost to the drop checker; it's not particularly large, but it's certainly not just a sequence of drop operations.

Don't get me wrong; I really enjoy rust, and I like it a lot. ...but those two ideas pop up repeated in discussions about it, and they're not exactly correct.