4 ms·

I love Android, but Java is the pits. I would love the libraries to be re-written in Go. How feasible is something like this, considering Dalvik is a major pie

by myko 14y ago

I love Android, but Java is the pits. I would love the libraries to be re-written in Go. How feasible is something like this, considering Dalvik is a major piece of the way Android behaves? Would the VM just go away? I really hope this is a skunkworks project happening at Google right now. Or actually I'd prefer it have major support up the chain, but I'll take a skunkworks project.

pkulak 14y ago
Dalvik is a major piece, but nothing is required to use it; there has been native support for a while now. Re-writing all the Android libraries in Go would be a heck of a project though, and then you'd have to maintain both forever. And I'm not entirely sure what the benefits would be, since I don't really know how Dalvik compares in runtime and memory use to Java 7. It would be pretty awesome though. I actually like Java, but developing mobile apps in Go would be a blast. Plus, Google could get entirely out of this Oracle situation if they transitioned entirely.
- grey-area 14y ago
  They'd be better off just starting again with a new minimal stack and API, with the lessons learned from their first iteration of the API (and I'm sure there were lots of things they'd do differently if they had the chance), run it in parallel, and gradually deprecate the old API as the new one gets up to speed, just as Apple has done several times over the past couple of decades (AppKit, UIKit etc). Moving a big group of developers from one API to another can be done, it just takes time, and a little judicious use of pressure... Android now has the installed base for developers to be forced to go along with whatever changes Google requires, and Dalvik could be kept around for quite a while as a backstop. I don't think the problems with Oracle are going away, so this might come to pass eventually, but I doubt it is on the roadmap right now.
scott_karana 14y ago
Considering that Go doesn't support shared libraries, it could make for really inefficient use of device RAM. Android's already a little heavy in that regard.
- sambeau 14y ago
  I was under the impression that even with shared libraries each running process gets its own copy of the library in its memory space.
  - vetinari 14y ago
    Yes, they do, but it is shared, copy-on-write (read-only for .text), meaning that although each running process has it mapped into its memory space, there is only one copy in physical RAM.
    - sambeau 14y ago
      For some reason I thought that was a fallacy. I must now go and re-read Tanenbaum.

by myko 14y ago

pkulak 14y ago

Dalvik is a major piece, but nothing is required to use it; there has been native support for a while now. Re-writing all the Android libraries in Go would be a heck of a project though, and then you'd have to maintain both forever. And I'm not entirely sure what the benefits would be, since I don't really know how Dalvik compares in runtime and memory use to Java 7. It would be pretty awesome though. I actually like Java, but developing mobile apps in Go would be a blast. Plus, Google could get entirely out of this Oracle situation if they transitioned entirely.

grey-area 14y ago
They'd be better off just starting again with a new minimal stack and API, with the lessons learned from their first iteration of the API (and I'm sure there were lots of things they'd do differently if they had the chance), run it in parallel, and gradually deprecate the old API as the new one gets up to speed, just as Apple has done several times over the past couple of decades (AppKit, UIKit etc). Moving a big group of developers from one API to another can be done, it just takes time, and a little judicious use of pressure... Android now has the installed base for developers to be forced to go along with whatever changes Google requires, and Dalvik could be kept around for quite a while as a backstop. I don't think the problems with Oracle are going away, so this might come to pass eventually, but I doubt it is on the roadmap right now.

scott_karana 14y ago

Considering that Go doesn't support shared libraries, it could make for really inefficient use of device RAM. Android's already a little heavy in that regard.

sambeau 14y ago
I was under the impression that even with shared libraries each running process gets its own copy of the library in its memory space.
- vetinari 14y ago
  Yes, they do, but it is shared, copy-on-write (read-only for .text), meaning that although each running process has it mapped into its memory space, there is only one copy in physical RAM.
  - sambeau 14y ago
    For some reason I thought that was a fallacy. I must now go and re-read Tanenbaum.