6 ms·

> 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

> 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
- tptacek 14y ago
  1. It clearly is a systems programming language. Pike has written whole articles about how difficult it has been to convince C++ people ot switch. 2. It clearly does have an extremely fast compiler. 3. It clearly is very fast, and Pike never claimed it was the fastest. 4. The GC works and is an active area of development. They are open about this. What do you want them to say? 5. Could you cite them actually saying Go was used all over Google?
  - pron 14y ago
    1. Maybe, depending how you define "systems programming language". Go, unlike Rust, is not really low level. Its just as "systems level" as Java is, and many C++ shops have switched to Java. So Go is like Java in that respect. Not a C/C++ replacement in the post-Java era. 2. Sure. Much faster than C++. But, as Go is really a Java alternative rather than a C++ alternative, the compiler is not that much faster than Java's. 3. Yes, but not fast enough as a C/C++ replacement. It's not even as fast as Java. 4. The Go team has made some interesting, and risky, design decisions with the GC. They write: "Go must support what we call interior pointers to objects allocated in the heap... This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector. So far, our experience comparing similar Go and Java programs shows that use of interior pointers can have a significant effect on total arena size, latency, and collection times." It will be interesting to see how this decision pans out. 5. I think he pretty much just did. Or, to be precise, he quoted what is likely a false prediction. It is true that both Go and Rust were first touted as a C/C++ replacement. Go clearly isn't while Rust clearly is. Go is a Java alternative minus the dynamic code-loading, and as such, hardly revolutionary. You get similar compilation speed, a slower runtime and none of the dynamic stuff. Go is sure a nice language, but Java shops are better off moving on to Clojure or Scala if they need a better language.
    - tptacek 14y ago
      The Go compiler is much faster than javac. I don't accept your premise of "Java is the floor for acceptable performance in systems programming languages". Plenty --- perhaps most! --- new serverside code is written in languages much, much slower than Java. I'm not sure if I accept your premise that Golang is consistently slower than Java (if it is, the difference is marginal). On the other hand, Golang code starts instantly and has no runtime requirement. I'm peripherally aware of some kind of rivalry between Rust and Go, but I'm not interested in discussing it; I use programming languages as tools to solve problems, not as tribes to join. When Rust is ready for prime time, I'll check it out and see if it solves any of my problems better than C, Golang, or Ruby, and if it does, I'll start using it. I have no plans to take seriously the idea of benchmarking the whole of Go against the whole of Rust.
- enneff 14y ago
  You should read this http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article which addresses points 1 and 2. As for 3 and 4, Go _is_ fast compared to a lot of languages, and has just gotten a lot faster. I think we're pretty realistic about the GC, in that we say it's simple and it works, and for most people it is more than adequate. We continue to spend a lot of time working on the GC. One thing we do say, however, is that unlike Java, Go gives you more control over memory use so that you don't need to put so much pressure on the garbage collector. 5 - there's a bunch of Go usage at Google that we can't talk about. It is being used increasingly all over the place, but growth is pretty organic at this point. The public things we can talk about, we do. The Google Downloads thing is not a small component, by the way, but rather the entire download server. We hope to release part of that as an open source project soon, so you can get an idea as to what it actually does. One of the more impressive things about that particular service is that it serves massive traffic with Go's built in net/http package.

> 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
tptacek 14y ago
1. It clearly is a systems programming language. Pike has written whole articles about how difficult it has been to convince C++ people ot switch. 2. It clearly does have an extremely fast compiler. 3. It clearly is very fast, and Pike never claimed it was the fastest. 4. The GC works and is an active area of development. They are open about this. What do you want them to say? 5. Could you cite them actually saying Go was used all over Google?
- pron 14y ago
  1. Maybe, depending how you define "systems programming language". Go, unlike Rust, is not really low level. Its just as "systems level" as Java is, and many C++ shops have switched to Java. So Go is like Java in that respect. Not a C/C++ replacement in the post-Java era. 2. Sure. Much faster than C++. But, as Go is really a Java alternative rather than a C++ alternative, the compiler is not that much faster than Java's. 3. Yes, but not fast enough as a C/C++ replacement. It's not even as fast as Java. 4. The Go team has made some interesting, and risky, design decisions with the GC. They write: "Go must support what we call interior pointers to objects allocated in the heap... This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector. So far, our experience comparing similar Go and Java programs shows that use of interior pointers can have a significant effect on total arena size, latency, and collection times." It will be interesting to see how this decision pans out. 5. I think he pretty much just did. Or, to be precise, he quoted what is likely a false prediction. It is true that both Go and Rust were first touted as a C/C++ replacement. Go clearly isn't while Rust clearly is. Go is a Java alternative minus the dynamic code-loading, and as such, hardly revolutionary. You get similar compilation speed, a slower runtime and none of the dynamic stuff. Go is sure a nice language, but Java shops are better off moving on to Clojure or Scala if they need a better language.
  - tptacek 14y ago
    The Go compiler is much faster than javac. I don't accept your premise of "Java is the floor for acceptable performance in systems programming languages". Plenty --- perhaps most! --- new serverside code is written in languages much, much slower than Java. I'm not sure if I accept your premise that Golang is consistently slower than Java (if it is, the difference is marginal). On the other hand, Golang code starts instantly and has no runtime requirement. I'm peripherally aware of some kind of rivalry between Rust and Go, but I'm not interested in discussing it; I use programming languages as tools to solve problems, not as tribes to join. When Rust is ready for prime time, I'll check it out and see if it solves any of my problems better than C, Golang, or Ruby, and if it does, I'll start using it. I have no plans to take seriously the idea of benchmarking the whole of Go against the whole of Rust.
enneff 14y ago
You should read this http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article which addresses points 1 and 2. As for 3 and 4, Go _is_ fast compared to a lot of languages, and has just gotten a lot faster. I think we're pretty realistic about the GC, in that we say it's simple and it works, and for most people it is more than adequate. We continue to spend a lot of time working on the GC. One thing we do say, however, is that unlike Java, Go gives you more control over memory use so that you don't need to put so much pressure on the garbage collector. 5 - there's a bunch of Go usage at Google that we can't talk about. It is being used increasingly all over the place, but growth is pretty organic at this point. The public things we can talk about, we do. The Google Downloads thing is not a small component, by the way, but rather the entire download server. We hope to release part of that as an open source project soon, so you can get an idea as to what it actually does. One of the more impressive things about that particular service is that it serves massive traffic with Go's built in net/http package.