the git-send-email format for a patch series is the cover letter (the one you are looking at) and then one message per commit (subsequent emails in the thread).
mailman is not the best interface for reading these; people would normally use their mail client, or specialised tools like patchwork.
I wasn't around for it, but didn't C grow fast during the 70s and 80s?
And didn't Java and JavaScript also spread pretty fast? Of course, Java was explicitly promoted and advertised by Sun, and JavaScript played off of Java's popularity and later became a web standard.
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 )
Regarding Java, it also helped that big Smalltalk players like IBM, decided to fully pivot into Java, and many Oracle haters might not realise that alongside IBM, they were the first ones to have alternative JVMs and were together with Sun in the Network Computer effort.
Smalltalk had a .NET like role in OS/2, one of the reasons SOM even supported metaclasses, just imagine the alternative universe.
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!
and with that the Internet. In 1990 UK higher education sites had "high speed" (megabit sometimes!) networking but they used X.25 "Coloured Book" protocols. There were a handful of well developed applications for services such as email, but experimenting with novel software on X.25 was difficult. In 1991 JANET (the people providing these network services to Universities, then and now) began JIPS, an experiment to try out Internet protocols.
Enthusiasm for JIPS was enormous. You could buy or, since you have an electronics department and an essentially inexhaustible supply of nerds, build, a Unix computer, and just like, write your own BSD sockets software. I hear a guy over a CERN has invented a World Wide Web we should check out... In less than a year JIPS ceased to be an "experiment" and by the time I arrived at a University a few years later X.25 was deprecated and few people cared that it was still technically available somewhere.
Rust is 8 years old and is still not fully stable (you need nightly for a lot of projects). Projects are planning and adding support but not many are actually using it yet.
Java was the hotest thing on the job market after only 3-4 years.
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.
I may have wrong assumptions, but I find it funny they didn't use Golang. Is it not capable of doing the same thing ?
Anyway, happy to see rust being adopted for that usage.
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.
> Since 80s everybody designs systems on top of C.
More like since the 1990's, as outside UNIX during the 1980's no one cared about C, and mostly thanks to the GNU Manifesto and FOSS uptake that took the steam out of C++ adoption being pushed by Apple, IBM and Microsoft.
I did a lot of cross platform development work from 1982 onwards and 1987 was very much the year of C for Intel | DOS machines - they were cheap (comparitively), widely available and Borlands Turbo C was a fully integrated IDE that was affordable (and|or pirated) with some outstanding manuals.
Between that and their ASM for low level work, C took off in a big way and Pascal sharply dwindled in popularity (although it still hung on for a long time, even up to the present).
In Europe, in a MS-DOS world without cross-platform considerations, it took until Windows 3.x release, and Watcom C++ with its DOS extender for folks to really care about C and C++.
In fact, we used Turbo C 2.0 to prepare our code samples to deploy them into a single Xenix computer shared across the whole school, and that was it, nothing else.
Watcom was a much much better compiler and was welcomed with open arms to be sure - I still have a copy of the last release and use it on occassions.
If we're waxing historic here, my first C compiler (of my own and not a university VAX | PDP version) was the Cain | Hendrix Small C compiler (released 1980) which I handcopied in 1982 and extended over the next year or three as I read the Dragon books and other works .. bit of a side exercise while doing an engineering degree and working on a sheep shearing robot.
Thank-you Dr. Dobb's Journal of Computer Calisthenics & Orthodontia
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.
The blog immediately put that statement into context, stating that the binary file actually ended up replacing most of their stack. At the end of the day, they ended up with about the same size binary size. Also, they were not even really trying to optimize for size.
It worked rather well for Xerox PARC, TI, Genera and others, had they not mismanaged their products, or fighting against workstations being built with a free beer OS.
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.
Reminds me of this blurb from djb's qmail security guarantee [0]:
> I've mostly given up on the standard C library. Many of its facilities, particularly stdio, seem designed to encourage bugs. A big chunk of qmail is stolen from a basic C library that I've been developing for several years for a variety of applications. The stralloc concept and getln() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits.
The other commenter mentioning Firebloom is correct that some firmware (iBoot family) has been using C w/ Firebloom extensions for a while. Parts of SEPOS also use Swift, which would make more sense as a non-C language than Rust, from Apple's perspective at least.
Apple does use Rust, though from job postings, we can infer it's more like network services than firmware.
Regardless though, I don't see how the implementation language of your firmware is locking you into a specific ecosystem, so this criticism seems misguided to me.
Ideally, Android wouldn’t have any security vulnerabilities, but that’s not realistic. Rust won’t prevent every bug (and it’s even possible to cause segmentation faults in an ostensibly safe language like Python), but “better” is still a huge leap forward.
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.
Just to add: OCaml also recently introduced a new memory model which promises that data races can only corrupt a bounded part of the program (basically, even stronger guarantees than Java does). It comes with some runtime overhead, but quite interesting development, you might find worthwhile to check out.
Speaking of race conditions, I recently looked into the current state of “make sure something is in the db and then retrieve it”. Absolutely bonkers that “on conflict do select” still doesn’t exist.
PostgreSQL's `INSERT... ON CONFLICT DO NOTHING` gets you there most of the way. You can add a `RETURNING` clause which will return the record that it inserted. But the manual reads like nothing will be returned if no insertion actually happened. So you'd have to follow up with a `SELECT`.
Ok, now enable us to let create Android Applications entirely in Rust (including the GUI). Let's get rid of Kotlin/Java monopoly in Android App development. Shall we?
Tell me you've never done any Android development, without telling me...
This is such a low-effort "take" without any effort to justify _why_ you'd want something like this. There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART).
At least with a language like Go, it somewhat makes sense, and has been attempted: https://gioui.org/
All this Java/Kotlin bashing is getting really old, especially for a forum like this one.
I didn't bash Java/Kotlin. In fact, I have written few android apps in Kotlin, Java and I also have fiddled with Jetpack compose, JNI and NDK (I have also played with mpv's Opengl/Vulkan's rendering on Android if that matters to you). I don't want to share the projects of mine because i don't want to reveal my identity.
I know that tailscale's android application is written in it but i don't think gioui is great for android apps.
> Tell me you've never done any Android development, without telling me...All this Java/Kotlin bashing is getting really old, especially for a forum like this one.
Ok, this one hurts. Why are you attacking me instead of defending your stance. All are allowed to have opinions and I am allowed to have one(It's sad to explain this to someone on forum like this one). 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 and where you don't want to be bothered/(vendor locked-in) by Bigcorps(looking at you Google services framework).
> write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART).
Haha, non-GC languages power the GUIs on Android fyi. Jetpack compose is powered by Skia. Chromium is powered by Skia. Skia is C++.
Please do your own research before commenting low-effort replies.
> 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.
> Skia is not something you use to write apps: it's a graphics engine, essentially something you use to draw polygons on the screen.
So, AOSP team can obviously create Rust framework ontop of Skia(or tinyskia,femtovg,etc.), make Android APIs available in Rust, Create proper widget framework and let us create Android Applications written entirely in Rust.
> 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.
I know what I am talking about. This is exactly the freedom that I was talking about. I am able to choose any framework/toolkit I want. If i don't want any framework, that's fine too. You don't have that freedom in Android. Everything has to be routed via Java ecosystem that AOSP constructed.
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.
> behind JNI walls, and even NDK code is obliged to make use of JNI to call into them.
What i originally told was "enable us to let create Android Applications entirely in Rust (including the GUI)" . Surely Google and AOSP projects can remove the restrictions that you mentioned and provide us alternative to Kotlin/Java ecosystem which is what i really want and hope them to do. Smartphones powered by Android are capable computers and freedom for App development is appreciated.
Please don't mention once again that "X is not implemented in AOSP. Y is required to make use of JNI calls into them". You know that this is superficial barrier and can be overcome/corrected if they wanted to.
There's a reason Chrome is mostly written in C++. Android's JVM system is a collection of Java wrappers around C++ libraries. There's some overhead in that translation layer, and it's unfortunate that you can't skip it. Even Google's own Flutter uses a C++ engine to run Dart applications.
Kotlin (and Java) is fast enough for many applications, but even with the recent advancements in ART, does have overhead compared to pure native code. I can't think of a reason why the API interaction overhead would pose a problem, but if Google themselves can find use cases for almost JVM-less apps, I'm sure there are reasons to give a Rust version a try.
> 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).
That doesn't change anything. Security was simply never what chrome (or webkit to be fair) was built around compared to speed of the insanely inefficient browser stack.
What does a GC have anything to do with it? You can reference count all the pointers if you want, you can expose JVM pointers in Rust where Rust doesn't manage the heap memory. There are plenty of easy solutions to work with the JVM
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.
> There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust
Sorry, what does the idea of a user interface have to do with garbage collection? They seem entirely unrelated at first blush, and it's not difficult to find GUI code written in rust.
You can technically create an Android app without any Java code. There are native APIs for graphics and input. However, as these are intended for games, you get a window into which you can draw... something. With OpenGL, for example. You don't get access to Android's regular UI framework. You will also have to go through the Java layer to do many things you might want to do — like requesting permissions or launching other apps' activities.
That's not really what's going on. Those "native" APIs you mention in most cases just call back to Java APIs under the hood. For better or worse, most of what Android is is written in Java. There's no hidden "C++" layer of Android to access.
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.
You can generate binder wrappers from aidl, that would work. This is fairly common when doing platform work (for those like me who work on the operating system rather than on apps).
However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.
You can call into any Android Java API from native code using JNI. It's not exactly convenient, but you are not limited to the C APIs exposed by the NDK.
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.
Does anyone have any experience creating production apps with Tauri? Seems like a sane alternative to Electron, especially if they can target all major platforms and keep the promise of smaller footprints.
Not quite production, but I was on a paid contract on a PoC. I would say back at 1.0, mobile was pretty painful and signing of any binary dependencies was up to you. It looks like they addressed signing in 1.5 and I haven't picked it back up to check out the mobile experience.
I don't think it's a good idea, mainly because android is multiplatform and rust, by it's nature, is only available for what it's built for. Unless you are giving google your rust code to compile, your app will be limited on it's reach.
All that said.
Rust doesn't have a GC so it'd (likely) have a lower memory consumption and could possibly be lighter on the CPU.
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.
Another benefit of rust assuming you are distributing binaries is you'll be able to use the latest version of Rust rather than being pinned to older versions of the SDK with partial support based on the whims of google.
> 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.
Not really, because not only it uses PGO, which most people using AOT languages never bother to learn, it only AOT compiles the code paths that JIT validated as being used, instead of the whole application.
JIT + AOT with PGO data shared across all Android devices on the planet, gets the best of both worlds.
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.
> Android is one platform: android. I thought rust worked across multiple operating systems.
Operating systems, not architectures. You'd have to cross-compile your application 4 times if you want to support all arms and x86s.
> 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.
It's not "just" port desktop programs. Android doesn't even use glibc.
So where is the patch?