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.
I think most of the complaints are about the user interface nowadays. It sometimes does have other problems, but that is probably because it takes a while for Yahoo to change.
After 12+ years of service they deleted my secondary email account because I hadn't visited it in less than a year ("username has been recycled"), then wouldn't let me re-claim the username, and have no support contact for it. I will never trust them with anything important.
You made me launch my old Yahoo account to be sure it's still there.
Then I tried to respond to an email in Yahoo! Mail, and EVERYTIME I HIT THE LETTER 'i' IT POPS UP A CHAT DIALOG BOX WTF. Sorry, but it's really frustrating.
Both the user interface and the spam filtering are awful. I only use it for a throwaway address (I personally don't pay for it, rohandhruva) so I've never tried any more "advanced" features. Why bother if it can't get the fundamentals right?
If you're also referring to the Gmail interface, it's because all the desktop clients I tried suck - this year alone I tried Thunderbird, Apple Mail, Microsoft Exchange and Mailbox and I can't even remember the apps that I tried on my iPad or on my Android. They all suck compared to Gmail's web interface.
Out of curiosity, have you tried Airmail on the Mac? I tend to agree with your observations about the clients you mention, but Airmail really stands out as excellent to me (although I like version 1 better than the recent version 2).
To get a time dilation of 1 hour = 7 years, the planet would have to either be moving extremely fast or be very deep in the black hole's gravity well (or both!). Either way, a dinky little shuttle craft is not going to have the power and fuel to get there and back.
Supposedly the signal from this planet had just been saying OK over and over again. We learn that is because of the time dilation--in local time, the probe just landed there a few hours ago. But in reality the time dilation would produce a Doppler shift on the probe signal. Instead of hearing "ok" over and over, they'd hear one super-slow "ok" signal at a super low frequency.
What did the guy on the Endurance eat for 23 years while he was waiting for them?
If the "frozen clouds" are dense enough to walk and land a spaceship on, how are they staying in the air?
Phil Plait (the Bad Astronomer) has been writing about where the science is off (he got a few things wrong in the first blog post though and followed up with another):
This bug has nothing to do with timeline freshness: the bug affected developers and not users. If you're having issues with the timeline, please report an issue here: https://www.facebook.com/help/181495968648557
