3 ms·

We've had a mostly different (positive) experience doing a similar thing at FullStory for mobile instrumentation, though I think I know where some of the key di

We've had a mostly different (positive) experience doing a similar thing at FullStory for mobile instrumentation, though I think I know where some of the key differences are. Our core "business logic" lives in Rust. This is a shared bit of code between Android & iOS that mainly deals with orchestration, serialization, and server communication. We managed to extract ~1/2 of each platform's native code into this shared orchestration. What's left on each platform is more like a platform driver. I fully admit that things are different for us because we're not dealing with a bunch of UI that we manage (instead we're dealing with UI that our customers have written in Java/Swift/Objective-C/etc), but I think that there's a few places where we've made this work in a better way: - We've chosen flatbuffers to serialize most (not all) of the data between the platform drivers and the shared library. - We're using a language that's a little more hip. It's still not very easy to hire Rust developers, but developers interested in Rust are _very_ interested. - We built tooling early on to make this pretty seamless. Our Rust code builds in XCode and gradle, so there's no real friction to a developer getting up and running. Our team is about a year in on this transition to Rust and so far it's helped us move far quicker, especially given the size of our team.

debt 7y ago
“Our core "business logic" lives in Rust.” Uh oh. So immediately you do understand that you have taken on the risk of potentially being unable to find any good(or bad) Rust engineers in the future, correct? Also they won’t be cheap as there won’t be many of them. A smarter, business-friendly, future-proof approach would be to have done that in Java. Future you will want you to have done that in Java, but if you’re trying to retain good engineers maybe I get the Rust thing.
- ahmedalsudani 7y ago
  I think many of the best programmers would jump at the opportunity to work with Rust. That might change if the language de jour changes but working with rust is a positive for many of the best people right now.
- mmastrac 7y ago
  I see you got downvoted here, but I think it is worth replying. We evaluated using Java on both iOS + Android (transpiled to iOS in some form), but what tipped the scales towards Rust was the "fearless concurrency" (that turned out to match the marketing) and the risk around the current state of transpilers. I was a fan of Java for a very long time. It was my language of choice from early 2000s to mid 2010s. It does _amazing_ things with keeping memory management out of mind (while still giving you the the "backdoors" to make things work well if you need a non-gc approach), but thread safety continues to be a glaring hole. From a former Java super-fan, I honestly think the future is Go + Rust. FWIW we also evaluated Go as a shared language, but there were risks around integrating our Go shared library with apps that may include some pre-existing Go code.
  - PunksATawnyFill 7y ago
    Why not Kotlin? Isn't it Google's anointed successor to Java?
bobajeff 7y ago
I'm planning on learning and writing mobile apps in Rust. I remember reading that some things aren't supported on Android and iOS. Has that caused you any issues?
- mmastrac 7y ago
  So far we haven't hit any roadblocks with the platforms being unsupported. I'm not sure exactly what others referred to, but in our case, our Rust code is effectively "headless". Under the hood, Android is very much a Linux-looking system and iOS is very much a Darwin/OSX-looking system, so as long as you avoid moving too far into the UI layers, they'll behave exactly as you expect.
  - bobajeff 7y ago
    Oh I'm glad to hear that. BTW I'm pretty sure I simply just misunderstood their platform support page. https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html
    - mmastrac 7y ago
      Oh yeah! Thanks for linking that. You are correct that Android/iOS are second tier, but TBH we have never seen anything to suggest that the stdlib is anything but 100% stable on those platforms. I did run into a bug with the rand crate running out of randomness on Android, but that's a different story. :)
manmal 7y ago
Kotlin Native comes to mind - it generates binaries that can easily integrated with gradle and cocoapods, complete with headers/interfaces. Do you also keep ViewModels or things like an AuthManager (incl Keychain) or view coordinators in Rust?
K0nserv 7y ago
That’s super interesting. I really like Rust, definitely my favourite language recently. I’ve been thinking a lot about the pattern you are using with Rust for the shared layer. Have you got an engineering blog or something with more details?
- mmastrac 7y ago
  There is a FullStory engineering blog, but as we've been pretty much heads down for a while on our product we've been unable to write up some of our internal discoveries. I'm hoping that we can open-source some of the mobile<->Rust glue (iOS + Android), and write up what we believe is effective sharing of business logic between platforms.
  - robocat 7y ago
    I would love GitHub to have a way to publish "example" code that is for reading, but not for using or branching. I have code that contains useful parts that are worth publishing, but it also contains horrorshow code and library/tooling specific dependencies that are useless to anyone else. I don't want to make the code useful for others, but I would remove comments/keys/PI, and parts of the code would remain useful to others to copy or use as a reference for how to do something. The main issue is avoiding getting roasted by some random dev blogger for some of the technical debt (the embarrassing code you remove or fix if publishing properly). Maybe a click-through agreement before you can read the code?
charlesdm 7y ago
As someone with plenty of C++ knowledge on mobile, I would expect there to be more C++ devs available with good mobile skills than there are rust devs? Maybe my own viewpoint is twisting the amount of devs I think are available, but I don't think the choice dropbox originally made was crazy. C++ is a great way to share complex code over multiple platforms (i.e. desktop + mobile) if you're running a relatively small engineering team with limited resources. Now, if you have semi unlimited resources, it makes sense to rebuild things natively for each platform in many cases. But Dropbox might not have been around, had they not maken the choice to share part of their codebase cross platforms.
- phonebanshee 7y ago
  As a first approximation, there are no C++ developers available. You're probably right that there are more of them than there are Rust devs, but filling a team with either one is going to be a very hard problem.

debt 7y ago

“Our core "business logic" lives in Rust.” Uh oh. So immediately you do understand that you have taken on the risk of potentially being unable to find any good(or bad) Rust engineers in the future, correct? Also they won’t be cheap as there won’t be many of them. A smarter, business-friendly, future-proof approach would be to have done that in Java. Future you will want you to have done that in Java, but if you’re trying to retain good engineers maybe I get the Rust thing.

ahmedalsudani 7y ago
I think many of the best programmers would jump at the opportunity to work with Rust. That might change if the language de jour changes but working with rust is a positive for many of the best people right now.
mmastrac 7y ago
I see you got downvoted here, but I think it is worth replying. We evaluated using Java on both iOS + Android (transpiled to iOS in some form), but what tipped the scales towards Rust was the "fearless concurrency" (that turned out to match the marketing) and the risk around the current state of transpilers. I was a fan of Java for a very long time. It was my language of choice from early 2000s to mid 2010s. It does _amazing_ things with keeping memory management out of mind (while still giving you the the "backdoors" to make things work well if you need a non-gc approach), but thread safety continues to be a glaring hole. From a former Java super-fan, I honestly think the future is Go + Rust. FWIW we also evaluated Go as a shared language, but there were risks around integrating our Go shared library with apps that may include some pre-existing Go code.
- PunksATawnyFill 7y ago
  Why not Kotlin? Isn't it Google's anointed successor to Java?

bobajeff 7y ago

I'm planning on learning and writing mobile apps in Rust. I remember reading that some things aren't supported on Android and iOS. Has that caused you any issues?

mmastrac 7y ago
So far we haven't hit any roadblocks with the platforms being unsupported. I'm not sure exactly what others referred to, but in our case, our Rust code is effectively "headless". Under the hood, Android is very much a Linux-looking system and iOS is very much a Darwin/OSX-looking system, so as long as you avoid moving too far into the UI layers, they'll behave exactly as you expect.
- bobajeff 7y ago
  Oh I'm glad to hear that. BTW I'm pretty sure I simply just misunderstood their platform support page. https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html
  - mmastrac 7y ago
    Oh yeah! Thanks for linking that. You are correct that Android/iOS are second tier, but TBH we have never seen anything to suggest that the stdlib is anything but 100% stable on those platforms. I did run into a bug with the rand crate running out of randomness on Android, but that's a different story. :)

manmal 7y ago

Kotlin Native comes to mind - it generates binaries that can easily integrated with gradle and cocoapods, complete with headers/interfaces. Do you also keep ViewModels or things like an AuthManager (incl Keychain) or view coordinators in Rust?

K0nserv 7y ago

That’s super interesting. I really like Rust, definitely my favourite language recently. I’ve been thinking a lot about the pattern you are using with Rust for the shared layer. Have you got an engineering blog or something with more details?

mmastrac 7y ago
There is a FullStory engineering blog, but as we've been pretty much heads down for a while on our product we've been unable to write up some of our internal discoveries. I'm hoping that we can open-source some of the mobile<->Rust glue (iOS + Android), and write up what we believe is effective sharing of business logic between platforms.
- robocat 7y ago
  I would love GitHub to have a way to publish "example" code that is for reading, but not for using or branching. I have code that contains useful parts that are worth publishing, but it also contains horrorshow code and library/tooling specific dependencies that are useless to anyone else. I don't want to make the code useful for others, but I would remove comments/keys/PI, and parts of the code would remain useful to others to copy or use as a reference for how to do something. The main issue is avoiding getting roasted by some random dev blogger for some of the technical debt (the embarrassing code you remove or fix if publishing properly). Maybe a click-through agreement before you can read the code?

charlesdm 7y ago

As someone with plenty of C++ knowledge on mobile, I would expect there to be more C++ devs available with good mobile skills than there are rust devs? Maybe my own viewpoint is twisting the amount of devs I think are available, but I don't think the choice dropbox originally made was crazy. C++ is a great way to share complex code over multiple platforms (i.e. desktop + mobile) if you're running a relatively small engineering team with limited resources. Now, if you have semi unlimited resources, it makes sense to rebuild things natively for each platform in many cases. But Dropbox might not have been around, had they not maken the choice to share part of their codebase cross platforms.

phonebanshee 7y ago
As a first approximation, there are no C++ developers available. You're probably right that there are more of them than there are Rust devs, but filling a team with either one is going to be a very hard problem.