Earlier quoted context omitted.
> The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. Or, you can also say that the adoption of LLVM compilers, Javascript/Node, Python, and Ruby, show that people are more into VMs than ever.
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.
Android Is a Dead End
11–20 of 71 posts
Re: Android Is a Dead End
#12Earlier quoted context omitted.
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…
> 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".
Re: Android Is a Dead End
#13Earlier 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.
between github, metasploit, and rails, ruby is falling out of favor the way that java has fallen out of favor.
Re: Android Is a Dead End
#14Most 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 given up.
Re: Android Is a Dead End
#15Re: Android Is a Dead End
#16Seems 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.
I understand what the author of the article is saying. Android seems to be flawed, on a business and an architectural level. I'm just not sure changing a programming language will fix that. The resource problems, in fact, arise from the lack of tight integration between hardware and software. Basically, iOS is more than just an OS. It's very tightly integrated with the hardware of the various iPhones. Those integration points are all revisited in every update to ensure no regressions, and often, to implement improvements.
Speaking of updates, that's another problem with Android. (If we're being fair, I think that problem too is a problem of the more loose hardware integration). But the fact remains that as long as the OS is yoked with the business requirement of being able to be deployed by any OEM, on any hardware they slap together... Android will have update problems. OEMs are sometimes trying to throw a 2.5 cent network chip onto a 40 cent phone and expect Android to handle it with all the speed and grace that iOS handles the rigorously vetted hardware and professionally customized, hand coded firmware that Apple puts in their phones. This is very difficult to do. In fact, I think it's unreasonable to expect that this can be accomplished at all in the market that Android OEM's have to operate in.
Google needs to decide what they want... do they want Android in the hands of the majority of device users? Because if they do... they are going about it absolutely correctly. (Afterall, Microsoft beat Apple SOUNDLY in the pc market... but the reality is that it required many Windows installations to run on some very unstable hardware builds.)
Alternatively, Does Google want to make better DEVICES than Apple? If this is what they want to do... yeah... Android is just NOT going to get them there. It probably is a dead end.
But either way... it's not because of Java, or Rust, or whatever programming language we're blaming it on today.
It really is a problem of ... let's be honest ... a lot of substandard hardware that OEM's are pawning off as being the same as the good stuff. As well as firmware that many of them just don't want to invest much time and money into perfecting. (Because the return on that investment is so low.)
You could change your VM and programming language tomorrow... you'd still have the problem of OEM's slapping cheap hardware and barely functional firmware into something that looks just like all the other Android phones and saying, "Buy MINE!!! It's cheaper!!!"
Re: Android Is a Dead End
#17Earlier quoted context omitted.
> The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. Or, you can also say that the adoption of LLVM compilers, Javascript/Node, Python, and Ruby, show that people are more into VMs than ever.
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.
Please elaborate, i'm interested.
Re: Android Is a Dead End
#18Seems 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.
These days, the Java code in an android app is compiled to native anyway.
Re: Android Is a Dead End
#19Earlier 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.
I believe that is how .NET works (the byte code gets distributed, and the user compiles it to native immidietly before execution).
Also, Android's ART is the replacement for Dalvik that compiles Dalvik bytecode into native code at installation.
Re: Android Is a Dead End
#20Earlier quoted context omitted.
> The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. Or, you can also say that the adoption of LLVM compilers, Javascript/Node, Python, and Ruby, show that people are more into VMs than ever.
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).