5 ms·

But it was pointed out upthread that animated GIFs aren't fully supported by the native Android libraries. So Rust would actually be a reasonable solution here.

But it was pointed out upthread that animated GIFs aren't fully supported by the native Android libraries. So Rust would actually be a reasonable solution here. It's true that there are costs associated with using Rust in the build process and so forth, but WhatsApp is trying to be a secure messenger and is FAANG-backed. The challenges can be overcome.

pjmlp 7y ago
Indeed, however Android does support other image formats with animation, which could have been another solution, much cheaper than introducing yet another language not directly supported by the OS SDK tooling.
- bluejekyll 7y ago
  > not directly supported by the OS SDK tooling. If that's an issue, I bet the Rust community is interested in making it easier and better supported.
  - pjmlp 7y ago
    Think about the Android development experience, using Android Studio, Gradle + CMake/ndk-build, mixed mode debugging across Java/Kotlin and native, Android Studio project templates for native code, packaging Android libraries, Bundles and Instant Apps, NDK APIs and Google libraries for Android intended for NDK consumption like Oboe. This are the expectations that any external language should meet versus what platform languages offer out of the box.
    - littlestymaar 7y ago
      I haven't done any android dev in a while so it may have changed in between, but it sounds that your expectations are higher than what the Android experience looks like when JNI is involved.
      - pjmlp 7y ago
        My expectations are what an Android developer using Studio 3.5 with NDK r20 would expect. While the experience is still found lacking versus what iOS or UWP tooling are capable of, it still is much better than any third party language integration.
- Diggsey 7y ago
  Changing to a different image format may not be possible because WhatsApp still needs to show historical images, and these images are not stored on a central server where they can be migrated. Also, it's called the "Android NDK" and not the "Android C SDK" - a big part of what the NDK gives you is not C-specific. It makes almost no difference whether you compile your code with GCC vs rustc, at the end of the day you're creating a native shared library and loading it from a java application. For example, these instructions from 2017 show how little work is involved https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html https://mozilla.github.io/firefox-browser-architecture/exper... and support has only improved since then. Using static analysis tooling on C/C++ code is more work than the above to set up, so I really do believe that Rust is the easiest way to reduce the chance of these kinds of bugs happening again.
  - deleted 7y ago
    [deleted]
  - pjmlp 7y ago
    Then they could add a memory safe Java library dependency like Glide. Yes it is called the NDK and the workflow that you describe doesn't support the bullet points I described. If Rust wants to be embraced by Android developers it needs to up its game in Android Studio tooling, Binder generation and FFI integration. Those instructions from 2017 are completely outdated given Android 3.5 and NDK r20. GCC is no longer around, C++ support has improved quite substantially, static analysis tooling is integrated into NDK, Android Studio 3.7 (planned for next year) will bring support for mixed mode NDK libraries in AAR format.

pjmlp 7y ago

Indeed, however Android does support other image formats with animation, which could have been another solution, much cheaper than introducing yet another language not directly supported by the OS SDK tooling.

bluejekyll 7y ago
> not directly supported by the OS SDK tooling. If that's an issue, I bet the Rust community is interested in making it easier and better supported.
- pjmlp 7y ago
  Think about the Android development experience, using Android Studio, Gradle + CMake/ndk-build, mixed mode debugging across Java/Kotlin and native, Android Studio project templates for native code, packaging Android libraries, Bundles and Instant Apps, NDK APIs and Google libraries for Android intended for NDK consumption like Oboe. This are the expectations that any external language should meet versus what platform languages offer out of the box.
  - littlestymaar 7y ago
    I haven't done any android dev in a while so it may have changed in between, but it sounds that your expectations are higher than what the Android experience looks like when JNI is involved.
    - pjmlp 7y ago
      My expectations are what an Android developer using Studio 3.5 with NDK r20 would expect. While the experience is still found lacking versus what iOS or UWP tooling are capable of, it still is much better than any third party language integration.
Diggsey 7y ago
Changing to a different image format may not be possible because WhatsApp still needs to show historical images, and these images are not stored on a central server where they can be migrated. Also, it's called the "Android NDK" and not the "Android C SDK" - a big part of what the NDK gives you is not C-specific. It makes almost no difference whether you compile your code with GCC vs rustc, at the end of the day you're creating a native shared library and loading it from a java application. For example, these instructions from 2017 show how little work is involved https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html https://mozilla.github.io/firefox-browser-architecture/exper... and support has only improved since then. Using static analysis tooling on C/C++ code is more work than the above to set up, so I really do believe that Rust is the easiest way to reduce the chance of these kinds of bugs happening again.
- deleted 7y ago
  [deleted]
- pjmlp 7y ago
  Then they could add a memory safe Java library dependency like Glide. Yes it is called the NDK and the workflow that you describe doesn't support the bullet points I described. If Rust wants to be embraced by Android developers it needs to up its game in Android Studio tooling, Binder generation and FFI integration. Those instructions from 2017 are completely outdated given Android 3.5 and NDK r20. GCC is no longer around, C++ support has improved quite substantially, static analysis tooling is integrated into NDK, Android Studio 3.7 (planned for next year) will bring support for mixed mode NDK libraries in AAR format.