5 ms·

I find this very hard to believe. One would expect Google to adopt Go, or perhaps Dart, since they were developed by Google.

clumsysmurf 11y ago
Bruce Miller, an Engineer at Google, answers this here: https://www.quora.com/Why-wouldnt-Google-use-Go-instead-of-Java https://www.quora.com/Why-wouldnt-Google-use-Go-instead-of-J...
freyr 11y ago
Despite Android's market share, some developers still write for iOS first and port to Android later (if at all). By moving to Swift, Google could reduce this friction and help prevent Android from being a second-class citizen among developers. Also, Go is a great language for writing networked systems software in. But it's not necessarily great for GUI-based application development. And there really hasn't been much effort to change that, from the Go team or externally.
- danielrhodes 11y ago
  Go was originally written to replace the things C++ is usually used for. There are many other languages which work well for higher level uses. I think the motivation behind creating Go was there weren't many new languages made to make writing systems level software easier.
  - freyr 11y ago
    > Go was originally written to replace the things C++ is usually used for. Go was originally written to replace the things C++ is usually used for within Google. C++ is used for many other things (embedded programming, games and graphics engines, etc.) that it doesn't seem like the Go authors were targeting. In fact, Pike said "we were pleased and a little surprised to find [Go] suitable for general-purpose programming" [1]. This suggests they weren't intending to create an across-the-board replacement of C++, since C++ is certainly a general-purpose programming language. Perhaps to a fault. > I think the motivation behind creating Go was there weren't many new languages made to make writing systems level software easier. The authors ran into issues describing it as a "systems language," since it's not really a systems language in the conventional sense (i.e., low-level language with fine-grained control over hardware and memory) [1]. Because C++ is used for conventional systems programming, and the Go team described Go as a C++ replacement, this probably ended up doing Go's reputation more harm than good. Pike and the Go team have essentially redefined "systems language" for their purpose, as a language targeting servers and interconnected systems. And it excels there. [1] http://www.informit.com/articles/article.aspx?p=1623555 http://www.informit.com/articles/article.aspx?p=1623555 [2] https://en.wikipedia.org/wiki/System_programming https://en.wikipedia.org/wiki/System_programming
- dogma1138 11y ago
  Many developers do that because that's where the money is. While Android has a larger market share Apple brings more money through app sales than Android. The Android ecosystem is also utterly segmented which means you have to support multiple versions of the API and a very wide range of hardware profiles which turns developing a consistent UX into a nightmare. On top of that you have to deal with emerging markets that sell android devices that don't even come with a play store and Google's APIs.
nostrademons 11y ago
I think you overestimate the extent to which Google acts as a top-down, unified company. It took about 5 years to get a single unified Google login. It took another couple before every property supported multi-login. GWT and Angular.js are both Google projects, but the vast majority of Google production services use Closure instead, and the Chrome team is pushing Polymer. AppEngine is used extensively internally, but the largest public-facing service on AppEngine that I know of is Fiber, which is totally dwarfed by the largest external customer of AppEngine (SnapChat). [At least, it was when I left in 2014; there was gonna be a big push into Cloud, so it's possible several other services have rewritten on top of GCP.]
deleted 11y ago
[deleted]
Zigurd 11y ago
Neither Go nor Dart are JVM languages. Both would have to be adapted to run in ART. It is difficult for Android to have more than one app runtime for apps that make more than trivial use of Android's framework.

clumsysmurf 11y ago

Bruce Miller, an Engineer at Google, answers this here: https://www.quora.com/Why-wouldnt-Google-use-Go-instead-of-Java https://www.quora.com/Why-wouldnt-Google-use-Go-instead-of-J...

freyr 11y ago

Despite Android's market share, some developers still write for iOS first and port to Android later (if at all). By moving to Swift, Google could reduce this friction and help prevent Android from being a second-class citizen among developers. Also, Go is a great language for writing networked systems software in. But it's not necessarily great for GUI-based application development. And there really hasn't been much effort to change that, from the Go team or externally.

danielrhodes 11y ago
Go was originally written to replace the things C++ is usually used for. There are many other languages which work well for higher level uses. I think the motivation behind creating Go was there weren't many new languages made to make writing systems level software easier.
- freyr 11y ago
  > Go was originally written to replace the things C++ is usually used for. Go was originally written to replace the things C++ is usually used for within Google. C++ is used for many other things (embedded programming, games and graphics engines, etc.) that it doesn't seem like the Go authors were targeting. In fact, Pike said "we were pleased and a little surprised to find [Go] suitable for general-purpose programming" [1]. This suggests they weren't intending to create an across-the-board replacement of C++, since C++ is certainly a general-purpose programming language. Perhaps to a fault. > I think the motivation behind creating Go was there weren't many new languages made to make writing systems level software easier. The authors ran into issues describing it as a "systems language," since it's not really a systems language in the conventional sense (i.e., low-level language with fine-grained control over hardware and memory) [1]. Because C++ is used for conventional systems programming, and the Go team described Go as a C++ replacement, this probably ended up doing Go's reputation more harm than good. Pike and the Go team have essentially redefined "systems language" for their purpose, as a language targeting servers and interconnected systems. And it excels there. [1] http://www.informit.com/articles/article.aspx?p=1623555 http://www.informit.com/articles/article.aspx?p=1623555 [2] https://en.wikipedia.org/wiki/System_programming https://en.wikipedia.org/wiki/System_programming
dogma1138 11y ago
Many developers do that because that's where the money is. While Android has a larger market share Apple brings more money through app sales than Android. The Android ecosystem is also utterly segmented which means you have to support multiple versions of the API and a very wide range of hardware profiles which turns developing a consistent UX into a nightmare. On top of that you have to deal with emerging markets that sell android devices that don't even come with a play store and Google's APIs.

nostrademons 11y ago

I think you overestimate the extent to which Google acts as a top-down, unified company. It took about 5 years to get a single unified Google login. It took another couple before every property supported multi-login. GWT and Angular.js are both Google projects, but the vast majority of Google production services use Closure instead, and the Chrome team is pushing Polymer. AppEngine is used extensively internally, but the largest public-facing service on AppEngine that I know of is Fiber, which is totally dwarfed by the largest external customer of AppEngine (SnapChat). [At least, it was when I left in 2014; there was gonna be a big push into Cloud, so it's possible several other services have rewritten on top of GCP.]

deleted 11y ago

[deleted]

Zigurd 11y ago

Neither Go nor Dart are JVM languages. Both would have to be adapted to run in ART. It is difficult for Android to have more than one app runtime for apps that make more than trivial use of Android's framework.