Bare-metal Rust in Android (opens in new tab)

C was definitely a player in the 70s and 80s (when it (and Unix) still had a lot of healthy competition), but it didn't attain its current veneer of ubiquity until approximately the early 90s (after being standardized in 1989). Javascript was derided as a joke until 2009 brought ECMAScript 5 and Node.js. Java's rise was relatively fast, but Java also had the benefit of the most concerted corporate ad campaign in the history of programming languages (how many programming languages have you seen advertised on TV? https://www.youtube.com/watch?v=FpirOZe1Cgk )

JavaScript was a web standard right from the beginning. Its popularity grew together with the web itself by virtue of being the only programming language that could be counted on to be available on websites.

Flash and Java both required plugins, didn't integrate well with the rest of the website, were quite heavyweight, and frequently got bad publicity due to security bugs.

Of course, browsers themselves also had them aplenty, but at the end of the day one can't use the internet without one :)

This is exactly right! I believe C's popularity grew so quickly because of its correlation with the popularity of Unix and its descendants. And yes, Sun pushing Java very hard certainly grew its adoption.

JavaScript is a really interesting case; initially, I don't think it was really taken very seriously. It was mostly tolerated because of its privileged status as part of the web platform. But since so much has moved from desktop application to the browser, that privileged status has proven all the more valuable!

Not at all, it was only relevant to UNIX users.

Your reasoning is not quite correct (rust’s nightly has no relevance here), but you are right in that Java seen an unprecedented growth, and probably no other language will ever demonstrate anything like that due to the “market” being so saturated since. Even if it would be the silver bullet language.

Not just garbage collection but also the way hardware work is done with languages that allow you to write one-to-one memory representations in order to be able to drive raw interfaces of hardware. A GC language almost always comes with a reference based type system that hides the very interfaces you'd like to access (fast) and adds deserialization overhead which has visible performance and battery life effects.

The other reason is C interoperation. All of the common systems rely on C. C is not just a programming language. Since 80s everybody designs systems on top of C. We ended up with OSes written in C that ship their tightly integrated C compiler that outputs binaries optimized for C's memory layout and primitives that the very same OS runs on silicon that's optimized to run C fast. C unfortunately became the meta-language of the low level APIs.

Go's interoperability with C is out of hell. Its green-thread scheduler doesn't play well with C. The foreign function interface is defined in the comments (!) of a source file and making CGo work on custom cross toolchains is full of hard to solve compiler errors.

Rust can operate at the same level as C easily and it has all the low level primitives. C interoperability is a core language function that's part of the syntax and standard library. It solves many gotchas of C without compromising speed.

The non-JVM code used in mentioned context will run in environments where yet another GC fighting the JVM GC isn't desired or have to be a shared library talking to existing JVM code. While you can use Go to build libraries with C calling convention, it's not the most supported use case and it shows in ergonomics. This also includes standard Go types and standard library which don't fit nicely into a model where code needs to talk a lot with JVM world.

It's possible... But it feels like screwing screws with a knife. It's doable, but noone from the language designers, stl designers and library developers are really thinking about that use case.

Rust on the other hand fits very well into the model where it needs to be just a piece of a bigger whole - it's been built that way ("system" programming language) and it doesn't come with GC that will fight with JVM or Binder lifetimes, compatible type system and plenty of libraries that help develop libraries on an embedded platform. When building the language, Rust designers consider this as one of the main use cases of the language and it shows with how much less hassle it is to work with.

The fact that it easily fits into existing C/C++ codebases helps too.

Binary size, for one. The blog mentions a binary file grew from 220kb (C) to over 400kb (Rust).

I also doubt a garbage-collected language work very well for drivers that require precise timing (MMIO) and/or control over memory allocation.

Go is garage collected

That can only compile a very limited subset of normal code.

But no need for that, Android already does AOT.

Not for Apple,

> Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code.

-- https://www.swift.org/about/

> Swift is a successor to the C, C++, and Objective-C languages

-- https://developer.apple.com/swift/

Swift is Apple's answer to replacing C derived languages, they don't need Rust.

> Swift is a successor to the C, C++, and Objective-C languages -- https://developer.apple.com/swift/

They also mention plans for kernel and firmware targets on that talk.

Possible related to the ‘-fbounds-safety’ feature they’ve proposed for Clang

https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...

Firebloom is more of a custom compiler/toolchain than a dialect of C—apart from annotations to relate pointer+length parameters, etc., it is still just C.

Nope. Race conditions are an ordinary fact about our universe, Rust has those. (Safe) Rust doesn't have data races which are much stranger.

Race conditions are just an ordinary effect where several actors are doing things and you need to be careful to ensure that they're co-ordinated properly if that's important. If Alice and Bob both conclude there's no milk, both then go to the store and buy milk, now there is too much milk.

Data races are because it's not possible to deliver what you intuitively expect from a computer which is capable of multiple notionally simultaneous operations. They have no analogue in our real world experience, which is why they're baffling for real programmers on non-trivial software. The world stops making sense.

Most programming languages which allow parallel computation have data races. In C and C++ they're just Undefined Behaviour. Game over. In Go they're sometimes not Undefined Behaviour if your race only touches very simple things like integers. In Java, interestingly, they're always defined behaviour but it doesn't help very much because the behaviour is extremely hard to reason about. Still, your program does do at least something sane even if your head hurts when you think about it. In safe Rust this never happens.

Pity that it is as good as C in producing UAF exploits, and doesn't have any story for binary libraries.

And Rust does better??

> Haha, non-GC languages power the GUIs on Android fyi. Jetpack compose is powered by Skia. Chromium is powered by Skia. Skia is C++.

Skia is not something you use to write apps: it's a graphics engine, essentially something you use to draw polygons on the screen.

> Why are you attacking me instead of defending your stance. All are allowed to have opinions and I am allowed to have one

I apologize if any of this sounded like an attack. I was trying to be funny with that meme-like sentence formation, but I don't profess to disparage anyone's skills or opinions.

> I dream of Linux-desktop kinda situation where you can program in any language you want, where you are not hindered by any platform/framework, where you have complete freedom

Linux desktop is certainly not the dream world you describe. Practically, you _have_ to pick a toolkit: one of GTK / KDE / Qt / electron / etc. Maybe it helps to think of Android's toolkit (Views or Compose) as one of those.

Calm down with that "Haha", all those native libraries powering Android are behind JNI walls, and even NDK code is obliged to make use of JNI to call into them.

Please do your own research on how AOSP is actually implemented.

> Android's JVM system is a collection of Java wrappers around C++ libraries.

This isn't even remotely true and it's obvious if you'd ever looked closely at Android. This take is as bizarre as saying that whole web/JS/React ecosystem is "just" wrappers on top of Skia.

> There's a reason Chrome is mostly written in C++.

And for that same reason, you don't see many apps do the same thing. Any time Chrome needs to request a permission (access files, location, etc), it _has_ to use the system-provided Java APIs.

> Even Google's own Flutter uses a C++ engine to run Dart applications.

As do most games, so you can essentially think of Flutter as a game engine that renders apps.

> Android's JVM system is a collection of Java wrappers around C++ libraries.

As others have mentioned, this is very much not the case.

At the same time, GUIs really don’t work nicely/as idiomatically without a GC. Most Rust GUIs do immediate mode only, which is a much more easier problem, and you won’t have to “argue” with the borrow checker constantly. But it would drain the battery of a phone in an hour (it would be the equivalent of running a proper 3D game as your notes app or whatever).

> There's a reason Chrome is mostly written in C++

Yea, security is not a concern. Apparently.

If you're willing to work with the JVM (i.e. through JNI), there's really nothing stopping you.

You can 100% make entire apps using nothing but C, C++, or whatever, as long as you're willing to interface with the JVM that's created for you to access Android APIs.

But the Android API is a JVM API. There's no getting around that. At this point, it's another OS (i.e. not Android) if it doesn't have Java in it.

Immediate mode vs retained mode. It is not a hard requirement, but the borrow checker definitely makes the latter more complex.

> Those "native" APIs you mention in most cases just call back to Java APIs under the hood

Some do, but most don't.

In theory it is possible to write raw Binder calls to various Android services, skipping JNI in many places. However, it is basically rewriting the entire OS API and structure from scratch.

Many Android APIs expect you to extend classes and implement interfaces for things like callbacks. You can't do that with JNI alone, you will have to have a .dex of your own anyway.

> Unless you are giving google your rust code to compile, your app will be limited on it's reach.

Android has supported native code in apps for a long time via the Android NDK, mainly to enable game development. The Android team seems to hate the NDK, but the alternative is to have no games on the platform, so they can't simply kill it.

> ...[native] ... It's not exactly great for runtime performance as it takes away some key optimizations.

In theory a JIT might produce better runtime performance than AOT compiled code, but in practice that usually turns out as wishful thinking.

VM warmup isn't consistently a thing, in fact for over a decade there has been plenty of observation of the reverse, that runtime optimization often slows performance. Systems languages (c/c++/rust) consistently outperform warmed up managed languages. And that is ok, it doesn't mean we shouldn't have managed languages, but they are slower.

>mainly because android is multiplatform and rust, by it's nature, is only available for what it's built for

Android is one platform: android. I thought rust worked across multiple operating systems.

>Rust doesn't have a GC so it'd (likely) have a lower memory consumption and could possibly be lighter on the CPU.

So what? I have never used G.C.

>Native compilation helps mainly with startup time and memory consumption. It's not exactly great for runtime performance as it takes away some key optimizations.

That is fair I suppose

I think the main benefit of rust/c++/ndk on android is that I can just port desktop programs and I don't have to learn android's java/kotlin and sdk.

I implore you to try Kotlin; it’s a fantastic language and is a wonder to code in