Earlier quoted context omitted.
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.
>I think cargo is better than cmake That is an understatement. I can't think of a build system that has spawned more attempts to find something better than CMake has. There have been so many people trying to make their own C/C++ build system and/or package manager out of sheer spite for CMake that it's frankly hard to keep track. In fairness to them and to CMake, it's not a simple problem to solve. To truly know CMak…
Rust in Android: move fast and fix things
51–60 of 430 posts
Re: Rust in Android: move fast and fix things
#52Earlier quoted context omitted.
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.
I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...
Re: Rust in Android: move fast and fix things
#53Earlier quoted context omitted.
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.
> I think cargo is better than cmake I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages). I absolutely agree if you aren't Google though.
If I were to go to another company I’d promote using either of the above.
Re: Rust in Android: move fast and fix things
#54Earlier quoted context omitted.
> I think cargo is better than cmake I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages). I absolutely agree if you aren't Google though.
Yeah my understanding is that google has some sort of God program they use that can compile anything and has 10,000 command line options.
Re: Rust in Android: move fast and fix things
#55Earlier quoted context omitted.
If they use Rust for new code and C++ changes are all in old code, this could be explained just by older code being more risky to change.
Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already. If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
Let’s end the C era.
Re: Rust in Android: move fast and fix things
#56Earlier quoted context omitted.
Nobody's stopping you from using the NDK to compile Rust though. Android's ABI is just an ABI like any other. The system doesn't care if you built an .so using Rust or anything else so long as it plays by the rules.
Some people rather reach out for first party support, instead of filling in the gaps for the big boys.
I could see the latter, although I'd still question whether they should be special cased in terms of a Rust dependency compared to bindings being hosted on crates.io.
Or maybe they should ship scripts that shell out to an existing Rust toolchain.
Re: Rust in Android: move fast and fix things
#57Earlier quoted context omitted.
I would expect memory safety vulns to be dropping in most C/C++ projects due to better practices
This contradicts what Google has reported about their own code, which is that most vulnerabilities are in new code
Re: Rust in Android: move fast and fix things
#58Earlier quoted context omitted.
> It's more of one additional anecdotal evidence that Rust is good. But that means it's likely to be the worst kind of science: - Group of people agree that Rust is good. This is a belief they hold. - Same group of people feel the need to search for argument that their belief is good. - The group does "science" like this. And then the rest of us have a data point that we think we can trust, when in reality, it's just…
> And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion. Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?
This isn't that.
Re: Rust in Android: move fast and fix things
#59Earlier quoted context omitted.
This doesn't 'cast' anything. The compiler prevents this because it would allow references that outlive their owners. Freely 'casting' only works for data that is static in nature anyways, at which point a coercion is taking place. Any other way involves `std::mem::transmute` or `Box::leak` and the like.
Here is a nice segfault in perfectly legal safe Rust https://play.rust-lang.org/?version=stable&mode=debug&editio... I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860
If the bar is "deliberately malicious code results in a segfault", get back to me when they fix
memcpy(0x10000, 0x20000, 0x10);
EDIT: and even that's being charitable; the Rust issue is viewed as a compiler bug which should be fixed.Re: Rust in Android: move fast and fix things
#60Earlier quoted context omitted.
Some people rather reach out for first party support, instead of filling in the gaps for the big boys.
By first party support, would you be expecting a Rust toolchain shipped in the NDK, or maybe Rust bindings shipped in the NDK? I could see the latter, although I'd still question whether they should be special cased in terms of a Rust dependency compared to bindings being hosted on crates.io. Or maybe they should ship scripts that shell out to an existing Rust toolchain.
https://developer.android.com/ndk
I expect the whole Rust build process being part of Android Studio, including mixed language debugging between Java, Kotlin and Rust.
I expect all NDK APIs to have Rust bidding crates.
I expect that Android developer forums also care to support devs using Rust.
And anything else that I forgot to mentioned, that is provided for Java, Kotlin, C and C++.