When I write Rust I tend to do so using functional/procedural patterns instead of object-oriented ones, and it doesn't seem like I run into issues like the ones described here very often.
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.
I don’t know about this. I think the trait system is so powerful of a concept for genetics and such that I find that I practice OO pretty regularly. I avoid dynamic polymorphism, but most OO practices translate really well into Rust.
I try to capture data in a enum or struct, then define the operations available to that type. A trait allows me to capture common functionality across different types which implement that trait. With generics it allows me to be polymorphic.
Well, technically traits dispatch based on type and not on value. As long as you aren't wrapping everything into trait objects that is much closer to functional programming. Seems like a mostly semantical difference, though.
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?
It's interesting, but overstated. It's more a description of how some Java patterns don't translate. For instance, the first example "encapsulation" demonstrates exactly no encapsulation.
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.
I think the part where they're trying to abstract out a `content` method could be made to work by adding braces, so that the `&self` borrow goes away earlier than the end of the function. I think "nonlexical lifetimes" are also going to make more cases like that work automatically without braces soon.
> I think the part where they're trying to abstract out a `content` method could be made to work by adding braces, so that the `&self` borrow goes away earlier than the end of the function.
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];
In the example from the blog post, content borrows the whole struct, and you can't drop the borrow earlier since it is used in the next line.
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
I think in the encapsulation / content example they missed the possibility of creating an explicit block on your own. I believe something like this would solve it:
let new_sum = { calculate it from self.content() }
self.sum = new_sum;
Since the sum value itself doesn't borrow anymore.
It's a useful lesson in that Rust's correctness relies on certain notions of borrowing dependencies which don't necessarily match what you assume. Especially that the lifecycle dependency across a function call is essentially opaque to the compiler.
Which is how it has to be, or you could never state anything sane about the lifecycle when you return a reference.
The "encapsulation" example is an interesting one, because it sits right in the fundamental difference between a Rust reference and a Java one, and the lifecycle considerations of a garbage-collected language vs one where lifecycles are statically determined by the compiler.
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.
> ... I introduced Gnirehtet, a reverse tethering tool for Android I wrote in Java.
> 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.
As far as I can tell it's not necessarily targeted at Android developers. It seems like the primary use case is if you have some device with cell service and you're out of WiFi range but want to use your Android device with an internet connection.
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.
I'm not the maintainer of the project, so I can't do that. Rust can cross-compile to that architecture though, so it should be possible, hence my reply.
You probably should file an issue so the maintainer actually sees it.
> 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 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.
Haskell is another language that compiles to native executables with minimal dependencies (binaries do link against libc, libz, and libgmp by default) which I think deserves more attention. It has great build tooling too (Stack).
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.
> Haskell is another language that compiles to native executables with minimal dependencies (binaries do link against libc, libz, and libgmp by default) which I think deserves more attention.
OCaml hits most of the boxes and would be more convenient/familiar to most users since it's strict and impure.
Rust is also pretty good at this, not quite as good as Go, but still generally pretty solid. Main related points:
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.
I suspect that "But at that time (early May), I was interested in learning Rust" was a big consideration there. But I can also vouch for Go's excellent cross-compilation support.
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.