4 ms·

In what way does Go scale badly from an engineering point of view?

justinhj 11y ago
It was our opinion that it's harder to write code that will be shared with a bigger team. Some of the factors were the simpler type system, lack of generics meant lots of copy and pasting of common patterns. The package system seemed less comprehensive and flexible in comparison to Java's. These are just subjective issues of course, but I think it's reaching a bit to say that Go and Swift are the best two languages you can learn.
- platz 11y ago
  Not a go fan, but seems like if anyone has scale problems, google would, and go would give them these issues too which is surprising since that was kind of the goal to solve from their perspective.
  - threeseed 11y ago
    There's different definitions of scale. He is talking about from an engineering perspective and at Google we have seen nothing other than a few periphery sites being written in Go. I fully agree that Go is a poor language if you are building a large, monolithic application.
    - sangnoir 11y ago
      > I fully agree that Go is a poor language if you are building a large, monolithic application. I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. So they either failed massively, or there's a difference in perspective on what a good language for programming in the large is. From Rob Pike's talk[1]: > Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects. 1. https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
      - coldtea 11y ago
        >I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. That doesn't mean much, if anything. One of the design considerations for Java was "write once, run everywhere" and that didn't turn out that well either. Most languages make failed or semi-failed promises. And their idea of addressing software development at scale, might not be 2015's idea of doing the same. Aside from Google, most other teams I've read using Go are more often than not writing small or medium-sized services, no big applications or highly complicated stuff.
        bliti 11y ago
        I share that experience. I use Go whenever the service is simple, requires better performance than Python, and cannot use too much instance resources.
      - netheril96 11y ago
        > I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. Isn't it hilarious that a statement from the Go authors could be used as evidence of its awesomeness given how the authors are naturally and heavily biased?
  - coldtea 11y ago
    >but seems like if anyone has scale problems, google would Google doesn't use Go at such large scale though. Some projects here and there, and most of them small for all I've read. The most publicly celebrated ones being a MySQL front-end for YouTube and a caching-layer (?) for Google Downloads. Not exactly earth shattering applications.
    - platz 11y ago
      These apps were the ones causing glacial compile times in c++?
      - coldtea 11y ago
        I don't think the ones "causing glacial compile times" have been replaced.
    - wbsgrepit 11y ago
      My understanding is that beyond the examples you talk about that go is being used extensively in google as a backend glue language for automation and services. https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
      - coldtea 11y ago
        >as a backend glue language for automation and services. Which again is not "at scale" (except in the sense that this automation manages thousands of servers etc). It's what people used to use Tcl, Perl, Python, etc for.
- 0942v8653 11y ago
  I'd agree with you about the type system, but what's wrong with the package system of Go? (I have little experience with Java's)

It was our opinion that it's harder to write code that will be shared with a bigger team. Some of the factors were the simpler type system, lack of generics meant lots of copy and pasting of common patterns. The package system seemed less comprehensive and flexible in comparison to Java's. These are just subjective issues of course, but I think it's reaching a bit to say that Go and Swift are the best two languages you can learn.

platz 11y ago
Not a go fan, but seems like if anyone has scale problems, google would, and go would give them these issues too which is surprising since that was kind of the goal to solve from their perspective.
- threeseed 11y ago
  There's different definitions of scale. He is talking about from an engineering perspective and at Google we have seen nothing other than a few periphery sites being written in Go. I fully agree that Go is a poor language if you are building a large, monolithic application.
  - sangnoir 11y ago
    > I fully agree that Go is a poor language if you are building a large, monolithic application. I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. So they either failed massively, or there's a difference in perspective on what a good language for programming in the large is. From Rob Pike's talk[1]: > Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects. 1. https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
    - coldtea 11y ago
      >I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. That doesn't mean much, if anything. One of the design considerations for Java was "write once, run everywhere" and that didn't turn out that well either. Most languages make failed or semi-failed promises. And their idea of addressing software development at scale, might not be 2015's idea of doing the same. Aside from Google, most other teams I've read using Go are more often than not writing small or medium-sized services, no big applications or highly complicated stuff.
      - bliti 11y ago
        I share that experience. I use Go whenever the service is simple, requires better performance than Python, and cannot use too much instance resources.
    - netheril96 11y ago
      > I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. Isn't it hilarious that a statement from the Go authors could be used as evidence of its awesomeness given how the authors are naturally and heavily biased?
- coldtea 11y ago
  >but seems like if anyone has scale problems, google would Google doesn't use Go at such large scale though. Some projects here and there, and most of them small for all I've read. The most publicly celebrated ones being a MySQL front-end for YouTube and a caching-layer (?) for Google Downloads. Not exactly earth shattering applications.
  - platz 11y ago
    These apps were the ones causing glacial compile times in c++?
    - coldtea 11y ago
      I don't think the ones "causing glacial compile times" have been replaced.
  - wbsgrepit 11y ago
    My understanding is that beyond the examples you talk about that go is being used extensively in google as a backend glue language for automation and services. https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
    - coldtea 11y ago
      >as a backend glue language for automation and services. Which again is not "at scale" (except in the sense that this automation manages thousands of servers etc). It's what people used to use Tcl, Perl, Python, etc for.
0942v8653 11y ago
I'd agree with you about the type system, but what's wrong with the package system of Go? (I have little experience with Java's)