[baq]

Ownership isn’t an advanced concept. It is a software engineering problem, not a rust problem. Rust is one of the few languages which make it explicit and even checkable at compile time and the first popular one.

What is hard is designing systems in a way resource ownership can be tracked and controlled without impacting performance. Rust makes it possible, but you can use smart pointers to give up speed and take simplicity instead. Most other languages assume (rightly so) you’re too dumb to do it correctly and give you smart pointers by default; some assume you’re smart enough and are proven wrong all the time (this is assembly and C relatives; actually they say ‘we don’t want smart pointers and we want a simple compiler, sucks to be you’).

[lenkite]

It very quickly becomes a special Rust-only software engineering problem. Rust has no partial borrows and this affects many designs where a lot of data needs to access fields of other data. Consequently, you see humongous large, flat structures in many Rust projects. And of-course, the famous "replace references with array indices" and just skip the borrow checking and lifetime rules by simply making your own custom pointer system - which is also common in many Rust projects and famously popularized by the "Object Soup is Made of Indices" Rust post here on HN.

[baq]

I assume you mean these are bad things; I see it as 'ownership enforcement pushing architecture towards memory safety' thing. Path of least resistance changes for the better - if you don't want to use a Box or a RefCell, that is.

[lenkite]

Yes, these are bad things. The extreme burden imposed by lifetimes and the prevention of easy refactoring for changes causes spectacular design bloat via workarounds and safety circumvention mechanisms which are unique to Rust projects. Its a special and necessary Rust skill.

[baq]

You only need to circumvent safety if you have it...

You can choose to have it in runtime. You don't get that choice pretty much anywhere else. If you don't want to make that choice in a granular way as rust allows, pick a language from the other two groups.

[wavemode]

No, Rust definitely does add some additional complexity on top of the inherent complexity of ownership. Despite what some people think, Rust's borrowing rules are actually extremely simple. So simple that they reject a lot of safe programs.

Paradoxically, programmer life would be made simpler if there were some more complex borrowing rules, that would allow (for example) partial borrows of objects, or allow aliasing &mut in single-threaded circumstances where it's known to be safe (i.e. when the data is something primitive like an int, where it doesn't actually matter if it's overwritten while referenced).

But I know there's extra language design complexity that this introduces, and extra codegen complexity (Rust makes certain aliasing promises to LLVM that it isn't allowed to break) so it will take time. But, there are proposals in the works.

[gpm]

> or allow aliasing &mut in single-threaded circumstances where it's known to be safe (i.e. when the data is something primitive like an int, where it doesn't actually matter if it's overwritten while referenced).

Incidentally this is basically what the `Cell` type does. I suspect that making it the default wouldn't make it harder for me to reason about the code I'm working on - but it is an interesting proposal.

[selfmodruntime]

Partial borrowing is not that much of a problem for the borrow checker. It is a problem for bikeshedding core language developers, apparently...