7 ms·

For those of us who are wondering if 1.1 is stable enough to upgrade: Google is already using Go 1.1 in production. And the company is betting big time on Go,

For those of us who are wondering if 1.1 is stable enough to upgrade: Google is already using Go 1.1 in production. And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years. Source: core dev on the golang team.

GhotiFish 14y ago
>And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years. !!! wow !!!
- mseepgood 14y ago
  Don't believe anything without a credible source citation. Not everything someone writes on the internet is true.
- trailfox 14y ago
  Wild speculation hardly == "wow"
netcraft 14y ago
im interested in the rewritten aspect - are these things that would have otherwise needed to be rewritten, or are you gaining benefits from the rewrite? Or is it an "eat your own dogfood" sort of deal? 50% of google's codebase must be significant, I can't imagine doing that "just because". And rewritten from what? C/C++ or python or something else?
- melvinmt 14y ago
  I'm not sure why, I also thought it was a bold statement coming from a Google employee and we'll have to see if they actually are able (and willing) to do that. But I can imagine, seeing how obsessive Google with performance usually is, that it mostly will be rewritten to save "millions of years" in optimizations. I believe Google is mostly using Java and Python.
  - BarkMore 14y ago
    > I believe Google is mostly using Java and Python. Google uses C++ for most compute-intensive code.
    - bradfitz 14y ago
      We don't use much Python. Mostly C++ and Java.
      - SiVal 14y ago
        Is Google's use of Python growing or shrinking? And how does it compare to your use of Go?
      - swah 14y ago
        The other day I was surprised to see that Go didn't have sets. After searching Google Groups, it was clear that the rationale is that "sets are easy to implement with hashmaps". I feel though that having a set, or a multiset, whatever... is exactly the kind of abstraction that makes it easy to think about your programs. In the end I felt that my Go port of some Python felt much more error prone that the original code.
        burntsushi 14y ago
        > I feel though that having a set, or a multiset, whatever... is exactly the kind of abstraction that makes it easy to think about your programs. I agree. But many abstractions meet that criteria. That doesn't mean you include it in the language. Also, it isn't just easy to implement a set with a map in Go, it's downright trivial: type Set map[string]int // Create set set := make(map[string]bool) // Add to set set["new element"] = true // Remove from set delete(set, "new element") // Membership test if set["new element"] { // "new element" is in the set } else { // "new element" is not in the set } Of course, this lacks common set operations like intersection, union, difference, etc. But in my experience, sets are most useful in their ability to represent a unique collection of elements with fast membership testing.
melling 14y ago
Some support for Android would be great. Go would make a great mobile development language.
- 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.
BarkMore 14y ago
I doubt that Google is rewriting 50% of their code in two years. Perhaps they said that 50% of new projects will be written in Go.
coldtea 14y ago
>And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years. Source: core dev on the golang team. They have been known to oversell the language. No way is the quote accurate.
- BarkMore 14y ago
  > They have been known to oversell the language. There's a lot of hype about Go, but I am not aware of cases where Google is overselling the language. Can you give examples?
  - coldtea 14y ago
    >There's a lot of hype about Go, but I am not aware of cases where Google is overselling the language. Can you give examples? Not Google. Just the Golang guys (Pike and co). 1) They sold it as a "systems programming language" at the beginning, to replace C/C++. When that didn't play well with actual system programmers, they reverted it to mean mostly server and similar back-end programming. 2) They emphasize as often as they can the "compilation speed", while for one is not a great concern for most projects, and second, other languages are just as speedy on that front. 3) They made claims of Go being "very fast" based on its statically compiled nature, whereas in practice it's slower than Java/Scala et co. 4) They downplay the fact that their GC is basically crap. 5) They make frequent statements about Go being used all around Google, but I've read Google employees deny that and say that it's use is quite marginal. The 2 greatest success stories they had offered are a simple component for Google Downloads (not the one that handles the whole thing) and a load balancer for MySQL fro YouTube. Not the kind of adoption to write home about.
    - pjmlp 14y ago
      Regarding issue 1, even though I tend to bash a bit Go regarding the lack of certain features, I have to defend it here. There are desktop operating systems being written in GC enabled system programming languages, namely Native Oberon and AOS. Both were and are used at Zurich Technical University (ETHZ) in operating systems research. In the late 90's some developers even used them as their main OS. You just need to have an escape mechanism to do the usual low level tricks, which is achieved by having a virtual package like unsafe, system or similar. The problem with getting new languages adopted for systems programming is that they will only get adopted if there is a mainstream OS that makes use of them thus forcing the developers at large to use it as such. Only now we see big companies replacing OS code that used to be written in C by C++. So how long it will take for any of the new contenders to defy C++ and in which OS? As for the Oberon systems, you might find this interesting, http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd... http://www.ocp.inf.ethz.ch/wiki/Documentation/Oberon http://www.ocp.inf.ethz.ch/wiki/Documentation/Oberon http://sage.com.ua/en.shtml?e1l0 http://sage.com.ua/en.shtml?e1l0
bradfitz 14y ago
I am a core dev on the golang team. Teams and engineers at Google can use whichever language they want. (trade-offs abound) We're trying to make Go be the most compelling language with the fewer trade-offs so they're willing to switch. It's getting increasingly popular. It's possible that 50% of new code will be written in Go in a couple years, but I've never seen that written as a goal. (And we do have goals. And usage charts over time, for each language, inside and outside the company, etc.) There's no way we'll rewrite 50% of all code in a couple years... there's so much code.
- melvinmt 14y ago
  Thanks for clarifying (can't edit my statement), the engineer I spoke to was wildly enthusiastic about Go so it may have been wishful thinking on his part. Even though it's clear now that the existing codebase won't be rewritten nearly as much, I still think it's cool that Google is considering to write 50% of all new projects in Go (if that part is still true). I'm hoping a lot of companies will follow.

GhotiFish 14y ago

>And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years. !!! wow !!!

mseepgood 14y ago
Don't believe anything without a credible source citation. Not everything someone writes on the internet is true.
trailfox 14y ago
Wild speculation hardly == "wow"

netcraft 14y ago

im interested in the rewritten aspect - are these things that would have otherwise needed to be rewritten, or are you gaining benefits from the rewrite? Or is it an "eat your own dogfood" sort of deal? 50% of google's codebase must be significant, I can't imagine doing that "just because". And rewritten from what? C/C++ or python or something else?

melvinmt 14y ago
I'm not sure why, I also thought it was a bold statement coming from a Google employee and we'll have to see if they actually are able (and willing) to do that. But I can imagine, seeing how obsessive Google with performance usually is, that it mostly will be rewritten to save "millions of years" in optimizations. I believe Google is mostly using Java and Python.
- BarkMore 14y ago
  > I believe Google is mostly using Java and Python. Google uses C++ for most compute-intensive code.
  - bradfitz 14y ago
    We don't use much Python. Mostly C++ and Java.
    - SiVal 14y ago
      Is Google's use of Python growing or shrinking? And how does it compare to your use of Go?
    - swah 14y ago
      The other day I was surprised to see that Go didn't have sets. After searching Google Groups, it was clear that the rationale is that "sets are easy to implement with hashmaps". I feel though that having a set, or a multiset, whatever... is exactly the kind of abstraction that makes it easy to think about your programs. In the end I felt that my Go port of some Python felt much more error prone that the original code.
      - burntsushi 14y ago
        > I feel though that having a set, or a multiset, whatever... is exactly the kind of abstraction that makes it easy to think about your programs. I agree. But many abstractions meet that criteria. That doesn't mean you include it in the language. Also, it isn't just easy to implement a set with a map in Go, it's downright trivial: type Set map[string]int // Create set set := make(map[string]bool) // Add to set set["new element"] = true // Remove from set delete(set, "new element") // Membership test if set["new element"] { // "new element" is in the set } else { // "new element" is not in the set } Of course, this lacks common set operations like intersection, union, difference, etc. But in my experience, sets are most useful in their ability to represent a unique collection of elements with fast membership testing.

melling 14y ago

Some support for Android would be great. Go would make a great mobile development language.

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.

BarkMore 14y ago

I doubt that Google is rewriting 50% of their code in two years. Perhaps they said that 50% of new projects will be written in Go.

coldtea 14y ago

>And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years. Source: core dev on the golang team. They have been known to oversell the language. No way is the quote accurate.

BarkMore 14y ago
> They have been known to oversell the language. There's a lot of hype about Go, but I am not aware of cases where Google is overselling the language. Can you give examples?
- coldtea 14y ago
  >There's a lot of hype about Go, but I am not aware of cases where Google is overselling the language. Can you give examples? Not Google. Just the Golang guys (Pike and co). 1) They sold it as a "systems programming language" at the beginning, to replace C/C++. When that didn't play well with actual system programmers, they reverted it to mean mostly server and similar back-end programming. 2) They emphasize as often as they can the "compilation speed", while for one is not a great concern for most projects, and second, other languages are just as speedy on that front. 3) They made claims of Go being "very fast" based on its statically compiled nature, whereas in practice it's slower than Java/Scala et co. 4) They downplay the fact that their GC is basically crap. 5) They make frequent statements about Go being used all around Google, but I've read Google employees deny that and say that it's use is quite marginal. The 2 greatest success stories they had offered are a simple component for Google Downloads (not the one that handles the whole thing) and a load balancer for MySQL fro YouTube. Not the kind of adoption to write home about.
  - pjmlp 14y ago
    Regarding issue 1, even though I tend to bash a bit Go regarding the lack of certain features, I have to defend it here. There are desktop operating systems being written in GC enabled system programming languages, namely Native Oberon and AOS. Both were and are used at Zurich Technical University (ETHZ) in operating systems research. In the late 90's some developers even used them as their main OS. You just need to have an escape mechanism to do the usual low level tricks, which is achieved by having a virtual package like unsafe, system or similar. The problem with getting new languages adopted for systems programming is that they will only get adopted if there is a mainstream OS that makes use of them thus forcing the developers at large to use it as such. Only now we see big companies replacing OS code that used to be written in C by C++. So how long it will take for any of the new contenders to defy C++ and in which OS? As for the Oberon systems, you might find this interesting, http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd... http://www.ocp.inf.ethz.ch/wiki/Documentation/Oberon http://www.ocp.inf.ethz.ch/wiki/Documentation/Oberon http://sage.com.ua/en.shtml?e1l0 http://sage.com.ua/en.shtml?e1l0

bradfitz 14y ago

I am a core dev on the golang team. Teams and engineers at Google can use whichever language they want. (trade-offs abound) We're trying to make Go be the most compelling language with the fewer trade-offs so they're willing to switch. It's getting increasingly popular. It's possible that 50% of new code will be written in Go in a couple years, but I've never seen that written as a goal. (And we do have goals. And usage charts over time, for each language, inside and outside the company, etc.) There's no way we'll rewrite 50% of all code in a couple years... there's so much code.

melvinmt 14y ago
Thanks for clarifying (can't edit my statement), the engineer I spoke to was wildly enthusiastic about Go so it may have been wishful thinking on his part. Even though it's clear now that the existing codebase won't be rewritten nearly as much, I still think it's cool that Google is considering to write 50% of all new projects in Go (if that part is still true). I'm hoping a lot of companies will follow.