3 ms·

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 i

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.
        swah 14y ago
        Thanks for answering. You're right, but in my case, I was adapting http://norvig.com/spell-correct.html http://norvig.com/spell-correct.html, and the set operation (constructor, actually) was exactly what I needed. Of course, it was simple to write a removeDuplicates fn that inserted elements from the array to a map, and back to an array. But that is the point of my parent comment... :) Once, while writing something in Java, I found out that I needed a Multiset (didn't knew the term) and that Java had a implementation. As strange as it sounds, that made me very productive and confident my code was working... (Of course, soon you're writing getters and setters and hating Java again..)
        burntsushi 14y ago
        Ah, I see. What if you represented a multiset as a map just like in my parent comment, but with integers instead of booleans? type Set map[string]int // Add to set set["element"]++ // Remove from set s[el] = max(0, s[el]-1) // Membership s[el] > 0 Here's a working example: http://play.golang.org/p/zMvVF1yERc http://play.golang.org/p/zMvVF1yERc N.B. This is a fiendish way of making good use of "zero" values in Go.
- enneff 14y ago
  > coming from a Google employee Who? I am convinced you have misheard, as nobody in their right mind would make that claim. We have a ton of code, and thousands and thousands of programmers, so it's just not realistic. These kind of hyperbolic statements are harmful as they build distrust in what we're doing. I, a Go core dev, have no interest in being anything but straightforward on this topic.
  - melvinmt 14y ago
    I won't name the source but I never intended to bring "harm and distrust" to the Go community (I really like Go). I can't edit my OP but thanks for clarifying the statement.

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.
      - swah 14y ago
        Thanks for answering. You're right, but in my case, I was adapting http://norvig.com/spell-correct.html http://norvig.com/spell-correct.html, and the set operation (constructor, actually) was exactly what I needed. Of course, it was simple to write a removeDuplicates fn that inserted elements from the array to a map, and back to an array. But that is the point of my parent comment... :) Once, while writing something in Java, I found out that I needed a Multiset (didn't knew the term) and that Java had a implementation. As strange as it sounds, that made me very productive and confident my code was working... (Of course, soon you're writing getters and setters and hating Java again..)
        burntsushi 14y ago
        Ah, I see. What if you represented a multiset as a map just like in my parent comment, but with integers instead of booleans? type Set map[string]int // Add to set set["element"]++ // Remove from set s[el] = max(0, s[el]-1) // Membership s[el] > 0 Here's a working example: http://play.golang.org/p/zMvVF1yERc http://play.golang.org/p/zMvVF1yERc N.B. This is a fiendish way of making good use of "zero" values in Go.
enneff 14y ago
> coming from a Google employee Who? I am convinced you have misheard, as nobody in their right mind would make that claim. We have a ton of code, and thousands and thousands of programmers, so it's just not realistic. These kind of hyperbolic statements are harmful as they build distrust in what we're doing. I, a Go core dev, have no interest in being anything but straightforward on this topic.
- melvinmt 14y ago
  I won't name the source but I never intended to bring "harm and distrust" to the Go community (I really like Go). I can't edit my OP but thanks for clarifying the statement.