I would love your opinion on whether migrating to Rust is a good idea for us, since you're experienced in this realm.
My team has a Java project that's written in a modern OO style. We defined "modern" OO as encapsulation and polymorphism, without inheritance, and it fits our use case very well.
We don't want to give up the benefits we get from the OO architecture, for good reasons that I won't get into here (because I don't want this to de-rail into a OO bash-fest, as fun as they are!)
The conundrum: In my experience, Rust doesn't support polymorphism very well. When the borrow checker meets polymorphism, a lot of state is forced into parameters (state which is inherent; we already keep state to an absolute minimum), which opens it up to mutation from all sorts of places; not very encapsulated.
We can have a bunch of private member Rc<RefCell<T>>s instead of bringing in all state via parameters, but it's unidiomatic, and in the end we'd probably have something slower and less safe than our original Java program.
The question: Is there any way to make Rust a good fit for a use case like ours?
(The same problems would apply to C++ codebases, though it's a little more convincing for them, since C++ isn't as safe as Java)
Not the GP, but is your problem that you have a complex object-graph without clearly defined owners of objects (as is common in GC'd languages, especially OOP ones)?
There's a pretty clear tree of ownership, actually. Looking at any given component, it's fairly easy to know when a component is a "subcomponent" (owned) or whether it's a reference to some other component elsewhere (borrowed). Some of us are C++ veterans, so we tend to think in terms of single ownership no matter what language we're in.
There are a few references in our "main" (so to speak) where its ownership would be clearer if we stored them in local variables and then handed them to the only component that used it, but that's a cosmetic concern, really.
There are very few (if any) places where we actually make use of Java's shared ownership. The only place I can think of is where we cache some files, and farm out "shared" references to any file. Still, at that point, the cache could be considered the owner, with a slight adjustment.
My team has a Java project that's written in a modern OO style. We defined "modern" OO as encapsulation and polymorphism, without inheritance, and it fits our use case very well.
We don't want to give up the benefits we get from the OO architecture, for good reasons that I won't get into here (because I don't want this to de-rail into a OO bash-fest, as fun as they are!)
The conundrum: In my experience, Rust doesn't support polymorphism very well. When the borrow checker meets polymorphism, a lot of state is forced into parameters (state which is inherent; we already keep state to an absolute minimum), which opens it up to mutation from all sorts of places; not very encapsulated.
We can have a bunch of private member Rc<RefCell<T>>s instead of bringing in all state via parameters, but it's unidiomatic, and in the end we'd probably have something slower and less safe than our original Java program.
The question: Is there any way to make Rust a good fit for a use case like ours?
(The same problems would apply to C++ codebases, though it's a little more convincing for them, since C++ isn't as safe as Java)