Live data from Hacker News

Android Is a Dead End

osnews.com

21–30 of 71 posts

Re: Android Is a Dead End

#21
This is a very confusing argument. The summary seems to be Android defined as "a Linux kernel with libraries" is a dead end. Well, okay, although given its deployment on 2B devices it's probably the best argument for Linux.

A couple of years ago Android replaced Dalvik, the runtime for all apps. Did anyone say Android is a dead end then? Nobody defines Android in this way, by a single component, and in a way the author even acknowledges this. You might as well say given enough time Linux itself is a dead end.

What Android is is what Andy Rubin originally said it would be - an open source mobile operating system. And I doubt this will be a dead end any time soon, certainly not in our lifetimes. Important libraries and frameworks themselves will be improved and replaced as they have been for many years now, and yes perhaps Linux itself will be succeeded. But why would anybody care, especially if its transparent to users and even to developers (I'd imagine maybe a Linux emulation mode for NDK users.) To me, this sounds like a healthy project, which is sort of the opposite of a dead end.

Re: Android Is a Dead End

#22
post #9

Earlier quoted context omitted.

JavaScript is moving away from VMs in a sense, since WASM has basically unmanaged memory (no garbage collector). That's a good thing, because in theory you could build your own GC on top of it. (I say in theory because the technology is not there yet, in particular on the concurrency front).

Wasm code is bytecode; it targets a VM.

True, but it's a very simple VM, as it doesn't have a GC.

Re: Android Is a Dead End

#23
post #14

Extend, engulf, devour. Most of the comments here miss the point of the article. The article author is saying that Google will replace the Linux component of Android with something proprietary. Then Google will have total control, and will be able to prevent Android clones. Already, Android apps make such heavy use of Google proprietary code that open source Android systems such as Cyanogen and FDroid have mostly giv…

Except that the only evidence provided is Fuschia which is open source

Re: Android Is a Dead End

#24
> over the coming two to three years, Android will undergo a radical transformation. This transformation will be mostly transparent to users - their next Android phone won't actually be "Android" anymore, but still run the same applications, and they literally won't care - but it won't be a Linux device, and it won't suffer from Android's core problems.

How laughable. Google can't even get most users on a two year old upgrade let a loan an entire rewrite.

Re: Android Is a Dead End

#25
post #7

Earlier quoted context omitted.

LLVM is not a vm, despite its name. Node is popular mainly because frontend people want to do backend work. Python is python, it's been around forever and is available. It's also unmatched in scientific realms. Ruby seems falling out of favor.

>Ruby seems falling out of favor. Please elaborate, i'm interested.

Well, I typically look at a few metrics as PL fascinate me a lot. However, I'll be the first to admit I'm not an expert, so take everything below with a grain of salt.

First I judge by new projects/tools that interest me. I don't see much ruby there, but a fair amount of python admittedly. This could be biased to what interests me, obviously.

The second is people I know. Some are ex ruby devs, none still use it in their line of work.

The third is job trends. Ruby, specifically Rails, is just down by any metric. A quick google search sent me to http://www.indeed.com/jobtrends/q-Ruby-on-rails.html

Again, I said 'seems' because it seems that way to me, not because it is fact.

Re: Android Is a Dead End

#26
post #3

So... there's absolutely no proof of what this article says, other than the existence of Fuchsia? Whose purpose we don't even know yet.....

Even is somehow Fuchsia replaces Android in the next 5-10 years what's the real concern?

Calling Android a dead end is pretty screwed up considering what has been accomplished with the operating system

Re: Android Is a Dead End

#27
post #12
post #8

Earlier quoted context omitted.

> people just aren't that into VMs anymore Bytecode can be translated quite well to native code. So I'm wondering if this isn't about "VMs versus native" as much as it is about "garbage collected versus unmanaged memory".

What's an example of an ahead-of-time compiler that takes bytecode and spits out native code? Can you do inline assembly for the target architecture? I heard a million time how JIT and JVM "could be" just as fast (or some claim faster) than AOT but in practice it hasn't happened. High performance code is written in AOT/native languages.

You can definitely do ahead of time compilation with .net bytecode. That's why you can write iOS apps in c# with xamarin's SDK.

I think the performance differences between JIT compiled code and native code mainly come from the 'convenience' features offered by languages such as Java or C#. I am thinking of garbage collection, (default) virtual functions or reflection.

In let's say c++ you can do all of these things too, but the cost is not hidden from the developer.

Re: Android Is a Dead End

#28
post #14

Extend, engulf, devour. Most of the comments here miss the point of the article. The article author is saying that Google will replace the Linux component of Android with something proprietary. Then Google will have total control, and will be able to prevent Android clones. Already, Android apps make such heavy use of Google proprietary code that open source Android systems such as Cyanogen and FDroid have mostly giv…

I don't think Google will do that anytime soon. Because they don't know how to make and sell a phone for profit. The only player that can do that is Samsung, and Google cannot cut them off. I bet Samsung would sell more tizen phones than Google would sell fuschia phones, if Google were to lock Android up.

Re: Android Is a Dead End

#29
post #4
post #2

Seems to me the long standing "Java is slow" versus "that's an old wives tale, Java software can be as fast native" all converges right down to the evidence of Android - compared to iOS, it's slow. If Java was just as fast then this would never come up.

Java can be performant, but still typically has a huge footprint and memory profile. Others will point out that there are multiple implementations of Java, which is true, but to what adoption? IMO, the only thing propping up Java is legacy enterprise and Android. The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. They had a place in the self hosted world, but in the microservice/cloud…

A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into memory, and control is immediately translated to this image (dynamic linking and runtime relocations complicate this a bit, but mainly involve patching the image).

Java on the other builds its process image on the heap, using the executable file as input. Nothing is executed out of the binary file directly afaik. I believe classloading (defined in the Java spec) actually prohibits doing too much of this work ahead of time. The JVM has to defer work until startup in case the user wants to define a custom classloader.

My knowledge of the JVM is very basic compared to my knowledge of ELF, but I believe the basic gist of this is correct. I'm interested in diggging into this difference more deeply and writing a well-researched blog entry about it.

Re: Android Is a Dead End

#30
Don't know if it's a dead end or not, but both the apis and the developer tools are a massive clusterf#%k compared to Apple and Microsoft. Just one head scratcher after another, especially if you dare to support older versions. In comparison, Apple has a relatively pain free API, and lets you access it with one of the most elegant languages I've ever programmed in (Swift). After delving into Android just for a bit, it is no surprise that there are so few decent, non-trivial apps for it, and even Google's own apps work better on iOS.
Post reply on HN