5 ms·

With a hostile owner of Java, it seems strategic to begin porting to a new runtime. I'm a little surprised its written in C++ and not go. Every step away from t

With a hostile owner of Java, it seems strategic to begin porting to a new runtime. I'm a little surprised its written in C++ and not go. Every step away from the JVM instruction set and disk formats is a harder case to make for patent/copyright infringement.

mscottmcbee 13y ago
Go is still very young. Doesn't make sense to write such a critical piece of software with it quite yet.
- devx 13y ago
  Yeah, they probably want to wait until Go 2.0 or something, before they commit Android to supporting Go (and support only 64-bit apps while they're at it, since from what I hear Go handles 64-bit much better than 32-bit anyway). So maybe in 2-3 years. But I do think they should do it eventually, and move away completely from Java, because I think Java is a pain to learn, especially for new programmers who want to make Android apps. Being able to write Go apps for Android could make Android that much more attractive to developers. In the meantime, this transition to ART apps, will be a huge benefit for users, as their apps will run better, especially on lower-end devices, which KitKat also addresses.
  - binarycrusader 13y ago
    Go isn't a panace either, especially when it comes to dealing with OS-level threads and goroutines.
- mortdeus 13y ago
  Go might be young but the underlying compiler suite is derived from Ken Thompson's c compiler written for plan9 ~25 years ago. Also taking into consideration that the people developing Go have an impressive history of innovation; its not an uncommon by the time somebody actually finishes developing that critical software, for the compilers and runtime to receive vast improvements via new useful diagnostic tools and optimizations.
- nl 13y ago
  Google have some pretty critical software running on Go already (and have for a couple of years now). For example, their MySQL scaling proxy[1] is in Go. [1] https://code.google.com/p/vitess/ https://code.google.com/p/vitess/
  - vidarh 13y ago
    But it is very different to use something server-side in your own environment where you can deploy updates easily, vs. client side on devices where the wrong kind of bugs can wreak havoc for millions of uses and make updates to fix them extremely much more complicated.
Someone 13y ago
Why? Dalvik already is a Google VM that has nothing to do with Sun's/Oracle's implementation (http://en.wikipedia.org/wiki/Dalvik_(software)#Licensing_and_patents http://en.wikipedia.org/wiki/Dalvik_(software)#Licensing_and...: "Google says that Dalvik is a clean-room implementation rather than a development on top of a standard Java runtime". It also is a register machine, while Java's VM is a stack machine.
pkulak 13y ago
I don't expect the runtime to be _written_ in Go, however, when I first saw this title, a little tiny piece of me was hoping it would be a runtime _for_ Go.
- Zigurd 13y ago
  So much of Android middleware is written in Java, and uses Android Java's IPC and RPC, a "second runtime" in Android would be a second class citizen. Android-in-Go, with the middleware in Go, would be a different OS. Maybe a good one, but it would not be Android.
- pjmlp 13y ago
  First the Go developers need to overcome a few religious issues, like support for dynamic loading.
pcwalton 13y ago
From the sound of things, this runtime does much more optimization than the Plan 9-based Go compilers do (it uses SSA), so if speed is the goal (and it looks like it is), Go wouldn't make much sense at this time.
- wmf 13y ago
  Of course if you write a JIT in Go the performance of the Go compiler is mostly irrelevant.
  - chongli 13y ago
    It's not the performance of the Go compiler that's at issue here, it's the resulting run-time.
deleted 13y ago
[deleted]

mscottmcbee 13y ago

Go is still very young. Doesn't make sense to write such a critical piece of software with it quite yet.

devx 13y ago
Yeah, they probably want to wait until Go 2.0 or something, before they commit Android to supporting Go (and support only 64-bit apps while they're at it, since from what I hear Go handles 64-bit much better than 32-bit anyway). So maybe in 2-3 years. But I do think they should do it eventually, and move away completely from Java, because I think Java is a pain to learn, especially for new programmers who want to make Android apps. Being able to write Go apps for Android could make Android that much more attractive to developers. In the meantime, this transition to ART apps, will be a huge benefit for users, as their apps will run better, especially on lower-end devices, which KitKat also addresses.
- binarycrusader 13y ago
  Go isn't a panace either, especially when it comes to dealing with OS-level threads and goroutines.
mortdeus 13y ago
Go might be young but the underlying compiler suite is derived from Ken Thompson's c compiler written for plan9 ~25 years ago. Also taking into consideration that the people developing Go have an impressive history of innovation; its not an uncommon by the time somebody actually finishes developing that critical software, for the compilers and runtime to receive vast improvements via new useful diagnostic tools and optimizations.
nl 13y ago
Google have some pretty critical software running on Go already (and have for a couple of years now). For example, their MySQL scaling proxy[1] is in Go. [1] https://code.google.com/p/vitess/ https://code.google.com/p/vitess/
- vidarh 13y ago
  But it is very different to use something server-side in your own environment where you can deploy updates easily, vs. client side on devices where the wrong kind of bugs can wreak havoc for millions of uses and make updates to fix them extremely much more complicated.

Someone 13y ago

Why? Dalvik already is a Google VM that has nothing to do with Sun's/Oracle's implementation (http://en.wikipedia.org/wiki/Dalvik_(software)#Licensing_and_patents http://en.wikipedia.org/wiki/Dalvik_(software)#Licensing_and...: "Google says that Dalvik is a clean-room implementation rather than a development on top of a standard Java runtime". It also is a register machine, while Java's VM is a stack machine.

pkulak 13y ago

I don't expect the runtime to be _written_ in Go, however, when I first saw this title, a little tiny piece of me was hoping it would be a runtime _for_ Go.

Zigurd 13y ago
So much of Android middleware is written in Java, and uses Android Java's IPC and RPC, a "second runtime" in Android would be a second class citizen. Android-in-Go, with the middleware in Go, would be a different OS. Maybe a good one, but it would not be Android.
pjmlp 13y ago
First the Go developers need to overcome a few religious issues, like support for dynamic loading.

pcwalton 13y ago

From the sound of things, this runtime does much more optimization than the Plan 9-based Go compilers do (it uses SSA), so if speed is the goal (and it looks like it is), Go wouldn't make much sense at this time.

wmf 13y ago
Of course if you write a JIT in Go the performance of the Go compiler is mostly irrelevant.
- chongli 13y ago
  It's not the performance of the Go compiler that's at issue here, it's the resulting run-time.

deleted 13y ago

[deleted]