Why do you think Swift and Rust are competing on the same grounds or for the same objective? Genuinely curious, i don't know much about Rust.
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.
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.
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.
The languages with tier 1 support on Android SDK tooling for app development, properly configured out of the box after a SDK full install.
https://developer.android.com/guide/components/fundamentals
Which by the way, also includes a phone emulator to try out your stuff, including simulation of hardware events.
No need to get a phone.
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.
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.
https://source.android.com/docs/core/architecture
So lets not pretend it is the same effort using Rust on Android, as it is for the official SDK languages.
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 can understand the appeal of abandoning Objective-C.
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.
Had Java been like Modula-3 or Eiffel since version 1.0, Go might never have happened at all.
Thankfully they are on the right path to fix those issues.
Additionally, AOT is still experimental, and doesn't support ASP.Net Core yet.
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++.
Sorry for the nit but Mozilla didn’t give us Rust. They sponsored some of its development but that was only 3ish years after Rust started.
Sitting hairs really.
the section on the future hopes for Swift similarly; it seems both Rust and Swift contend to replace C++ in many use cases
This "lower-level Swift" felt like a similar problem to what Carbon or Herb Sutter's Cpp2 have. They've got something that's unsafe, and they want to somehow build a safe abstraction, but that's a foundation layer, and you've already built a tower of stuff above that, so you need to build it underneath all the stuff you have, which will be way harder than what Rust did where they begin at the bottom.
Is it impossible? No. But it might well be too expensive to be pulled off in practice, especially given that you need the result to pay back your expense over and above what exists today e.g. Rust.
Writing Rust applications is also very ergonomic. The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks.
The only Rudy lacking ergonomics is writing net new frameworks or missing framework pieces, or when std is not available.
95%+ of all new Rust code will fall into the bucket of “ergonomic to write and read”.
The pain of adding third party C++ dependencies is undeniable, especially in a cross-platform manner. I've had the displeasure of maintaining three different C++ build systems in 3 different companies, and they were all a nightmare.
Contrast that with cargo that just... works.
This is also, if not more, true for Swift as well. I've been working with both Swift and Rust (in addition to C++) for some time now and I find real-world, advanced Rust SIGNIFICANTLY easier to read and comprehend than real-world, advanced Swift. This is, IMHO, due to the fact that where Rust chooses to be syntactically simple, explicit and consistent, Swift chooses to be syntactically complex, idiom-based and feature-bloated. Sure, Swift code can look very modern and attractive at times, but usually when it comes to superficial code samples in Apple promotional videos. Otherwise, if you, say, look at a large codebase written by someone else, Swift reads just as badly as C++ complexity-wise.
None of them are ergonomic for non-trivial applications!
The goal is to appropriately abstract away the super minority of code that deals with the non-trivial parts into a nice ergonomic interface.
Rust is frankly better than most in the list above at allowing the writer to create an ergonomic interface. Yes it’ll take the writer 3x as long in the short term to create the ergonomic interface but:
1. Relative to everything else creating/maintaining these types of internal abstractions is a super minority of time spent reading and writing code.
2. Unlike other languages, you’ll end up with fewer iterations of the interface because it’ll push the author to really understand the complete interface, rather than shipping a buggy interface that needs iteration. Also refactoring is Rust is simpler than any other of the listed languages (because it self documents more assumptions).
3. The ergonomic interface likely has already been published as a crate. I.e. don’t need to write it at all. These internal abstractions are more likely to be written in their first pass as general purpose than in other languages because of the collaborative design working with the rustc compiler.
I agree! You’re currently dealing with writing non-ergonomic Rust.
I’d argue your domain is missing a fundamental reusable library/framework or the framework is currently missing a piece. Once someone publishes the needed library (hopefully it’ll be you) then everyone consuming it can just Lego block multiple crates together. Lego blocking crates together (barring heavy macro crates) is very ergonomic.
95% of all new code written is Lego blocking other crates. 5% of new code written is to build new or improve/patch crates.
I don't think that's true at all, at least it wasn't for me. Async in Rust has always been hard for me, it seems that using it requires knowing about how exactly it works and how your runtime of choice works. This is a lot, and requires a lot of time.
The documentation in Rust is above average, however the Rust ecosystem tends to be very unstable. Libraries often pull lots of depencies, many of which aren't even in 1.0, some that have switched to a new version but still have docs made for the old. The guideline from semantic versioning is to release 1.0 as soon as people start depending on it, since the idea is to version the public API. This is not always respected. And goes hand in hand with libraries that are 4 years old and on version 12 or something.
I remember actix-web before the 4.0 being particularly hard to get into.
We saw the other day where C and C++ just let you write what seems reasonable but then they do something insane, D says no, that's a syntax error, but Rust's diagnostic gives a name to what you intended, says you can't do that, and suggests how to write it instead.
if (a < b < c)
Edited to add:
Swift says: adjacent operators are in non-associative precedence group 'ComparisonPrecedence' -- which is definitely better than D, but it doesn't offer the helpful suggestion.