I watched a Rust intro video recently that provided a perspective I liked, so I’ll share that here: MS, Apple, Google (and more) all relied heavily on C for low level code that needed to be as performant as possible. It turned out though that C‘s memory management is so problematic that many/most security issues are caused by it. To address that, Google invented Go, Apple made Swift, Mozilla gave us Rust etc.
MS is interesting - they tried to write memory safe C and invested heavily, but admitted defeat eventually - and started using Rust. And I think that’s what will happen at most companies eventually. Rust has a lot going for it (faster than C sometimes, excellent WASM support etc). Swift might have been another contender, but Apple kept things too close to their chest for too long IMO.
As another poster wrote, Swift certainly won’t die at Apple (and their ecosystem), and Google will certainly keep Go alive. But I think Rust will eventually be used at many/most other companies for anything security or performance critical. Maybe it will replace C as the de facto low level language.
If it was just a matter of avoiding memory safety Java and ML were right there, and these languages are pretty different from each other.
It's not just memory safety. Go gets motivated by highly concurrent systems with large numbers of programmers and prioritized simplicity and developer experience. Rust was aiming at very high performance at the extended of complexity and compile times, and Swift wanted to build UI hierarchies.
ML is still right there, and yet people are adding its features to more popular languages (recently Java). OCaml had a compiler to JS released in 2010 (js_of_ocaml), yet Typescript was still released 2 years later. Is this because of technical concerns? NIH syndrome? Lack of knowledge about absolutely everything that has been done? A need for control? Probably a bit of each, and other things too.
No it didn't, it created C# because they got sued by Sun due to the J++ extensions, none of them were related to value types and AOT.
J++ extended Java in having a Windows specific framework JFC, Java Foundation Classes, what later became Windows Forms.
Support for events and J/Direct, which is basically how P/Invoke came to be on C#.
.NET has always supported a basic kind of AOT via NGEN, which only supports dynamic linking, AOT has to be done at install time, requires strong named Assemblies and it is tailored for fast startup leaving the rest of the work to the JIT.
If it wasn't for the lawsuit, C# would never happened, in fact the research being done with COM vNext used J++.
Currently the Android team doesn't have any plans to expose Rust support on the NDK/AGK, anyone going down that path is expected to support themselves in Android Studio, Gradle, CMake, android-ndk, AAR/Bundles, JNI integration.
Nothing of that covers "Android Studio, Gradle, CMake, android-ndk, AAR/Bundles, JNI integration", which an Android shop expects to have out of the box support in the Android SDK installer.
Note that android-ndk in that comment means the original Makefile based build tooling, which CMake builds still lack some corner cases in functionality, hence why I listed both.
So, just to be clear, in what languages do I not need to "support myself" under your definition and what does the "support" consist of?
Do I get an Android test phone to try my software out? Is there like free phone support so I can chat to some expert in my language about Android problems? You make it sounds like a pretty big deal, but my small experience† of writing Android software a decade ago was that it just wasn't that hard.
† I wrote an implementation of the now obscure mOTP (similar to TOTP) for in-house usage. For obvious reasons I named This One Time app "Band Camp" which was already a pretty old reference at the time but once I thought of it I couldn't help myself.
I just tried this and... no C++. You can add the NDK and start building stuff with C++, but that's also exactly how the Rust offering works. If the result was actually a properly configured out of the box C++ development environment that would be pretty nice besides the Android stuff, but it isn't, the actual result out of the box is you get to pick Java or Kotlin.
You can do C++ native development for Android, but only via basically the same route as Rust, there's just not the huge gap you implied.
Since when does Rust appear as language selection on the NDK installer?
Has out of the box support on Android Studio for:
- mixed language debbugging
- project templates wizard
- code completion and linting
- JNI bindings generation
- two way editing between native JNI wrappers and Java/Kotlin native method declaration
- packaging of Android libraries for native code
And for game developers, if they so which, plugins for Visual Studio with similar capabilities.
In both cases, official support from Android team if there are issues with the above tooling.
Apparently you haven't tried enough, if you think bare bones NDK integration with cargo is enough for Android shops.
Maybe Rust will get on https://developer.android.com some day, but it isn't there today, even despite the fact that it is being used for Android internals, there is zero documentation on how to write Android drivers in Rust.
Since editing window is already out, I am not arguing against Rust, and would welcome first class support for Rust on the Android tooling (Android/VS Studios, NDK, AGDK, Modules/Bundles) and being visible across https://developer.android.com documentation.
Can’t speak for Rust (but I hear that it is now quite mature -it predates Swift), but I’ve been programming Swift, since the day it was announced. In that time, the language, itself, has matured; possibly to the point that it’s starting to look a bit “Swiss army knife”-like.
I’m not exactly your typical jargonaut. I’ve been writing software since 1983. Been through a lot of changes, paradigms, and just plain old bullshit, in that time. I don’t really go for “shiny,” just because all the kids are into it, these days.
I do not claim everyone coding Swift or Rust is a novelty-seeker; rather, novelty-seekers were drawn to those languages, and will be drawn to others as they appear.
I can understand the appeal of abandoning Objective-C.
“Rust grew out of a personal project begun in 2006 by Mozilla Research employee Graydon Hoare. Mozilla began sponsoring the project in 2009 as a part of the ongoing development of an experimental browser engine called Servo. The project was officially announced by Mozilla in 2010.”
MS is interesting - they tried to write memory safe C and invested heavily, but admitted defeat eventually - and started using Rust. And I think that’s what will happen at most companies eventually. Rust has a lot going for it (faster than C sometimes, excellent WASM support etc). Swift might have been another contender, but Apple kept things too close to their chest for too long IMO.
As another poster wrote, Swift certainly won’t die at Apple (and their ecosystem), and Google will certainly keep Go alive. But I think Rust will eventually be used at many/most other companies for anything security or performance critical. Maybe it will replace C as the de facto low level language.