[pjmlp]

You surely do, first of all the borrow checker is only a compiler validation that you are writing the manual code correctly, and no one is magically writing Drop traits implementations for the user.

Likewise on the C++ side, someone has to write those constructor/destructor pairs, and there are ways to get RAII wrong.

[cmrdporcupine]

Seriously, no, re: Rust.

Yes, you have to think about ownership. Because of single owner. But in general, not alloc/free. I work in Rust (after doing C++ for the 10ish years prior) full time and a couple nights ago was honestly the first time I had to really think about this (I had to do a 'forget' because I was passing a ptr to a vector back through from WebAssembly to our Rust-based runtime, and then clean it up back there instead of having Rust let it fall out of scope and free when the stack frame exited).

Think of Rust as a world where pretty much everything is inside a std::unique_ptr.

Most developers used to a GC language will have little problem working in Rust once they understand the single ownership model.

[pjmlp]

Try to write a native GUI application in Rust, or async code, and you will see how little you have to think about it.

[cmrdporcupine]

Yes, GUI work is a pain because of the way event loops and ownership in existing UI toolkits work, they're generally not designed for this. But Arc<Mutex< is likely your friend here.

Async can be a pain, but you learn the ways. I work in a codebase with quite a bit of it.

There are appropriate and inappropriate places to apply Rust.

[pjmlp]

It surely is my friend, and I will need to manually call clone() and borrow().

[hobofan]

> no one is magically writing Drop traits implementations for the user.

Yes, the compiler is - for almost all structs. I've been working with Rust since around 1.0 and I can count the number of times I manually had to write Drop implementations with my hands. Unless you are writing lower-level parts of the stack (which you rarely need to, since for many of those there are good crates already available) where you are responsible for resources that need a custom Drop implementation, the auto Drop implementation is good enough.

[pjmlp]

Trivial types don't count, their Drop implementation is basically do nothing.

And for Rust standard library, where the Drop actually does something, someone else wrote the implementation for you.