Patiently waiting for the Rust APIs to arrive . . .
Java feels so heavy, so getting to use Rust would be a breath of fresh air.
(Kotlin has been better, but it also requires the JVM.)
> Managed languages like Java and Kotlin are the best option for Android app development. These languages are designed for ease of use, portability, and safety.
You're not going to write Android Activities in Rust. Nothing is stopping you from adding Rust code to your Java/Kotlin app though.
An other approach would be to employ one of many thin webview wrappers, in which your app is HTML+Js+CSS. When such a webview wrapper supports WASM, the JS part could be written in rust.
Not something I'd do other than "to prove it can be done".
But, TBH, I think Kotlin and Java are _indeed_ fine application languages.
What Rust is already quite often used for is for libraries that work on both iOS and Android. For a public example, see the Glean SDK: https://mozilla.github.io/glean/book/index.html
I agree wholeheartedly.
But there will be a demographic of people who know Rust and not Java, but who might want to build an app. Somewhat similar to how there is an apparent need for "HTML+JS+CSS"-devs to build native apps.
I'm not sure if the argument for "HTML+JS+CSS" is purely familiarity, there's also technical arguments like portability and future-compatibility. But I _do_ hope that the portability story will become better in the coming years beyond just this stack.
The big problem with such a setup, of course, is that the application itself would be running inside a JVM/Dalvik VM, so the app would constantly be switching between Java and native, which can't be great for performance. However, it can be done; thankfully, Chrome and Firefox aren't completely compiled to byte code, the JIT and rendering code is written in native code. With Mozilla's use of Rust in their browser, that means that there's already a significant Rust runtime running on Android, at least.
If the app uses Rust and a library to hook the draw call, it should be fairly easy to write the app like a video game and render everything in Rust. This would come bundled with a tonne of accessibility problems, of course, as every rendered control would be a non-standard one.
I've put a lot of time into learning Rust and I still reach for Java for high level stuff. GC is just wonderful for developer productivity. Lifetimes are way better than C but still a PITA.
Especially when you mix with threading, you end up using Reference Counting anyways which is just shitty GC.
Memory safety is a big deal for writing secure programs, which has been repeatedly shown to be impossible to do at scale in C++. Provably safe parallelism and concurrency is key for performance on multi core devices, also extremely difficult to do safely and correctly in C++.
If C++ is the wheel being reinvented, it's not much of a wheel.
I maybe break out rust-gdb once a year. My code has fewer bugs than ever, thanks to extensive use of the high-quality modeling tools (types and lifetimes) provided by the language. My main project for the last year has had a grand total of one logic bug that was caught after release.
It also has an inclusive community: at the last RustConf, half the speakers were nonbinary and/or transgender. I fit both those criteria and feel more welcome in the Rust community than in that of any other language, meaning that I can do my best work in Rust.
Just to clarify, I'm asking with good intent.
The Rust community has many nonbinary and transgender people in it, and speakers are selected from the community. The selection process for RustConf is blind so the talks were picked for their merit: it just so happened that half of the speakers weren't cis.
> rust is a very unique community
Yes, this is true in my experience.
One thing I will say is that my general impression from afar is that Europeans are generally a lot more tolerant of the state interfering in personal identity issues than the liberal parts of the US. Iceland used to have a fixed list of approved baby names for example, something unimaginable in the US.
The situation was made better in 2019: https://www.icelandreview.com/news/icelandic-names-will-no-l...
It varies from acceptance of an adult just being trans, of trans babies, of schools preaching medical transition without parent approval, and of issue of bathroom usage and sex-segregated prisons.
Regardless of the political questions presumably Swedes are fairly liberal about someone's personal choices.
Put another way and exaggerated wildly for hopeful clarity, if person A became an expert despite being shoved away, and person B was wooed into the group, had tutors, friends,... I'd be more interested in A's talk than B's.
I'm not even going to say why because it would be a huge rant. It improves on C++ in virtually every way. Every feature you have in C++, Rust does it better. Every feature you wish C++ had, Rust has it.
I agree with you on Kotlin. It's better than Java on paper, but in much the same ways Groovy already was. And the advantages are shrinking in new versions of Java, especially if you use Lombok.
How does one perform generic fold expressions in Rust lang ? (Possible in C++ 17 and above)
https://foonathan.net/2020/05/fold-tricks/ https://en.cppreference.com/w/cpp/language/fold
IDK. I miss variadic functions (not macros) and being able to do certain simple things without resorting to strange paradigms, like arbitrarily closing an std::fs::File without needing to go out of scope or calling drop. Things like that.
Why “drop” is the opposite of “open”? Let’s change “open” for “lift” or “notdrop”.
It's hard not being sarcastic in reply to this. But no, this did not happen.
> now supports the Rust programming language for developing the OS itself.
So, this seems to be about in Android, not building apps for Android.
Guess we'll see with more posts!
Certainly, there are some _apps_ on Android today that use Rust (shout-out to my Firefox friends!), but that's not something I'm investing in right now.
I expect replacing low-level C++ with Rust to result in improved platform reliability as well as reduced security bugs.
For every weird memory safety bug that is usefully exploitable there are a hundred more that just mysteriously break things and may be very difficult for a human to spot. My WebAuthn tests broke on my Pixel 2 on Saturday, I spent about an hour trying to debug the problem, wondering why it was happening now but not before and why it didn't affect other platforms - then I rebooted the phone and it went from reporting a "NotReadableError" about the secure local storage to just working.
Rust is not a UI programming language and shouldn't be.
but writing your own native modules in rust might be fun (VR, Audio processing, AI ...)
Rust seems like an excellent contender for the future.
If you have enough threads passing stuff around and can deal with the ~50% performance loss between Java and Rust, it's much easier to use a language with GC.
There's talk of adding a quality GC to rust and dedicated GC types. If/when that happens, Rust will be a contender for a bunch of higher level systems
UIs tend to have designs that require graph based structures and self referencial references, so in the end you get either lots of Rc<RefCell<>> and clone() calls, or have to bind the whole stack to fit into Rust's memory model.
Have a look at,
https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020....
https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
I'd still much rather use the standard SDK and kotlin and I absolutely adore rust.
*There are already unofficial ndk crates for rust.
This is actually an area where iOS is more flexible. Because UIKit is C-accessible, it’s feasible to develop bindings to it for other languages, and even autogenerate them. It’s too bad the same isn’t true of Android Framework.
Google is planning to fix this eventually.
Android's API is also atrocious.