5 ms·

I would easily pay 3x the Xamarin price for a Xamarin-like platform for Rust. And I'm pretty sure I'm not alone. It's the perfect language for a mobile platfor

I would easily pay 3x the Xamarin price for a Xamarin-like platform for Rust. And I'm pretty sure I'm not alone. It's the perfect language for a mobile platform, and I would love to use the zero-runtime-cost abstractions without resorting to the C++ hand-grenade roulette. The fact that it has an ML heritage, with all the goodies that entails (ADTs, pattern matching, type inference, etc), is even better.

vvanders 11y ago
Yup, put me in that camp as well.
- brson 11y ago
  It's going to happen, and it's going to be glorious!
  - saosebastiao 11y ago
    Please tell me more!
    - brson 11y ago
      OK, imagine... You run a single command to instantiate a family of cross-platform Cargo projects, one your platform-agnostic backend, and one for each of your target platforms: Linux, Windows, Mac, Android, iOS, of course, but also the entire impending IoT down to the smallest real-time device. Your platform-specific projects come with safe Rust bindings to the system platform (ala Xamarin). Another single command builds and tests this from a single host system on an armada of virtual machines, emulators and cloud systems. Your tests run on a wide variety of standardized machine images, including those used for upstream Rust's own integration testing. Another single command packages this for various Linuxes and app stores, deploys to your devices and cloud services. Three commands, total world domination :)
      - saosebastiao 11y ago
        Take my money!
      - Touche 11y ago
        How are you going to bridge between rust and the Android Java apis?
        vvanders 11y ago
        There's already quite a few JNI wrappers out there for pure-native activities.
        SneakerXZ 11y ago
        But you need to automate it, you need something that generate JNI wrappers and that it generates Rust wrappers around it and vice versa. With ObjC, you have similar problems and same goes for C#. It would be nice but I don't think it will happen anytime soon.
moonchrome 11y ago
I think people overestimate Rust as an application programming language. It has some nice features but at the end of the day their focus is safety above all else - this actually creeps up all over the place - requiring you to be explicit, APIs requiring you to deal with every possible error type (even the ones you don't really want to deal with), etc. Error handling was still very messy last time I checked. You know what makes you productive with high-level (often dynamically typed) languages ? Optimistic programming - you write some code and do the least amount of work to run it and see how far it gets you. Maybe a part of it fails under some condition, maybe some default assumption turns out to be wrong, etc. ... You can live with that because you got something working in fraction of the time it would require you to handle all the edge cases and type out all the bits and peaces up front. The sooner you get to run the sooner you get to iterate. And that's ignoring the cost to iteration time because of compile time. Rust has it's design goals - it's trade-offs are decent for the context they are made in - but it isn't my idea of high productivity application programming language.
- saosebastiao 11y ago
  My very first use case for rust was to replace a ruby script that was running too slowly. The script did some free form text parsing and mathematical postprocessing, and then dumped out a huge load file for SQLite. It took me much longer to initially write than the ruby script...but after throwing in all the debugging and error handling after the fact with the ruby script, I spent about half as much time writing it in rust. And that was with 2 years experience with Ruby and zero experience with rust. There is a lot to be said about a language that is strict, strongly typed, and with an emphasis on safety. If I'm shipping a product with my brand name attached to it, I would so much rather catch easy bugs at compile time than run time.
  - bpicolo 11y ago
    There are higher-productivity, strongly/statically typed languages out there that are probably more reasonable for typical applications programming
    - 11y ago

vvanders 11y ago

Yup, put me in that camp as well.

brson 11y ago
It's going to happen, and it's going to be glorious!
- saosebastiao 11y ago
  Please tell me more!
  - brson 11y ago
    OK, imagine... You run a single command to instantiate a family of cross-platform Cargo projects, one your platform-agnostic backend, and one for each of your target platforms: Linux, Windows, Mac, Android, iOS, of course, but also the entire impending IoT down to the smallest real-time device. Your platform-specific projects come with safe Rust bindings to the system platform (ala Xamarin). Another single command builds and tests this from a single host system on an armada of virtual machines, emulators and cloud systems. Your tests run on a wide variety of standardized machine images, including those used for upstream Rust's own integration testing. Another single command packages this for various Linuxes and app stores, deploys to your devices and cloud services. Three commands, total world domination :)
    - saosebastiao 11y ago
      Take my money!
    - Touche 11y ago
      How are you going to bridge between rust and the Android Java apis?
      - vvanders 11y ago
        There's already quite a few JNI wrappers out there for pure-native activities.
        SneakerXZ 11y ago
        But you need to automate it, you need something that generate JNI wrappers and that it generates Rust wrappers around it and vice versa. With ObjC, you have similar problems and same goes for C#. It would be nice but I don't think it will happen anytime soon.

moonchrome 11y ago

I think people overestimate Rust as an application programming language. It has some nice features but at the end of the day their focus is safety above all else - this actually creeps up all over the place - requiring you to be explicit, APIs requiring you to deal with every possible error type (even the ones you don't really want to deal with), etc. Error handling was still very messy last time I checked. You know what makes you productive with high-level (often dynamically typed) languages ? Optimistic programming - you write some code and do the least amount of work to run it and see how far it gets you. Maybe a part of it fails under some condition, maybe some default assumption turns out to be wrong, etc. ... You can live with that because you got something working in fraction of the time it would require you to handle all the edge cases and type out all the bits and peaces up front. The sooner you get to run the sooner you get to iterate. And that's ignoring the cost to iteration time because of compile time. Rust has it's design goals - it's trade-offs are decent for the context they are made in - but it isn't my idea of high productivity application programming language.

saosebastiao 11y ago
My very first use case for rust was to replace a ruby script that was running too slowly. The script did some free form text parsing and mathematical postprocessing, and then dumped out a huge load file for SQLite. It took me much longer to initially write than the ruby script...but after throwing in all the debugging and error handling after the fact with the ruby script, I spent about half as much time writing it in rust. And that was with 2 years experience with Ruby and zero experience with rust. There is a lot to be said about a language that is strict, strongly typed, and with an emphasis on safety. If I'm shipping a product with my brand name attached to it, I would so much rather catch easy bugs at compile time than run time.
- bpicolo 11y ago
  There are higher-productivity, strongly/statically typed languages out there that are probably more reasonable for typical applications programming
  - 11y ago