Much of this write-up seems to cover things that were/are complicated because of OOP's tight coupling of state and actions on that state & the intersection of that with the additional constraints and controls Rust places on state management.

I'm not entirely sure which style/patterns are more idiomatic. I just know which ones keep me out of trouble.

If that’s not OO, I don’t know what is :)

I guess there is a philosophical difference in whether you pass a large struct into a function or select the needed data at the call side and only pass that, though. Former might be easier to extend, latter is probably easier to test?

In general terms although sometimes you need to do things like this, shared mutable state is something you should be avoiding in any language and you should thank Rust for making it harder on you.

It demonstrates a kind of getter, but a weird one since it returns a mutable field. These are not the most encapsulated thing.

Not in that case. It helps when dropping a borrow earlier avoids to violate the borrowing rules, like in this case:

    let mut a = [0; 20];
    {
        let b = &mut a[2..4];
    }
    let c = &mut a[6..8];

I think there’s a missing guide out there for people like myself who have an OO background, are looking to write some rust but can’t reconcile the borrow-checker with how they normally design software

try this

    let new_sum = { calculate it from self.content() }
    self.sum = new_sum;

But the point was to show that a compiling program may not compile anymore after factoring some code into a private method.

Which is how it has to be, or you could never state anything sane about the lifecycle when you return a reference.

Using mutable references is the minimal way to get this.

I guess one way to explain it, if one needed to, is to say that the Java object is effectively a collection of Rc<RefCell<T>>, and getters return copies of those Rc<>s. (Okay I know, garbage collection is not the same as refcounting, but in this kind of analysis it's effectively the same).

Makes me sit back and think how much work Java the language is doing for you here.

> At Genymobile, we wanted Gnirehtet not to require the Java Runtime Environment, so the main requirement was to compile the application to a native executable binary.

While it is nice to see new projects adopting Rust, I really don't get the point of having a tool targeted to Android developers not depending on Java.

They must have customers that are in that situation somewhat regularly (traveling business people?) and keeping the overhead low is desired.

Is there a possibility to have the RUST Version compiled for an ARM architecture?

I'm running it on a Raspi3 as a tether box. Obviously less CPU consumption would be an enormous advantage. , since with the java version transmit speed only reaches arround 50 kbit/s.

Thank you very much for your great work!

You probably should file an issue so the maintainer actually sees it.

While I think that rust is a great choice, if multi platform static executables is your goal then I think you missed a language that does such a thing extrmely well. I’m surprised the author didn’t even consider Go for this purpose.

  * memory safety without garbage collection,
  * concurrency without data races,
  * abstraction without overhead

> But at that time (early May), I was interested in learning Rust, after vaguely hearing what it provided, namely:

And then he listed what you listed in your comment.

As he wrote the main requirement was not to include JRE. This could also be achieved by using Go.

I have been responsible for building and deploying Python, JVM, and Haskell projects to production servers. For Haskell projects it was pretty much painless, Python and JVM were "challenging". The main advantage comes from having native binaries and a good build system that does the right thing, which Rust is also good at.

OCaml hits most of the boxes and would be more convenient/familiar to most users since it's strict and impure.

Rust code is statically linked by default. C code you link to may not be. Many -sys packages (that wrap C libraries) give you an option to link statically or dynamically.

libc isn't statically linked by default, so that's usually the only thing not-statically linked in a pure-Rust program. You can use musl instead if you'd like.